From 2ba86f6640c912dd7be91917854d6068551ce5ec Mon Sep 17 00:00:00 2001 From: Andrei Rosseti Date: Thu, 16 Apr 2026 23:28:37 -0300 Subject: [PATCH 01/20] feat: pt-br locale --- astro.config.mjs | 45 ++- src/components/Footer.astro | 19 + src/components/Header.jsx | 15 + src/content/docs/br/docs/assets/image.png | Bin 0 -> 100415 bytes .../compliance/responsible-disclosure.mdx | 70 ++++ .../br/docs/compliance/security-audit.mdx | 24 ++ src/content/docs/br/docs/data-apis/index.mdx | 5 + .../docs/br/docs/features/amendments.mdx | 184 +++++++++ .../br/docs/features/balance-adjustments.mdx | 70 ++++ .../docs/br/docs/features/burn-2-mint.mdx | 291 ++++++++++++++ .../developer-tooling/client-libraries.mdx | 10 + .../developer-tooling/curated-tooling.mdx | 16 + .../developer-tooling/developer-tricks.mdx | 29 ++ .../br/docs/features/faucet-and-explorer.mdx | 27 ++ .../docs/br/docs/features/governance-game.mdx | 199 ++++++++++ .../http-websocket-apis/admin-api-methods.mdx | 67 ++++ .../http-websocket-apis/considerations.mdx | 16 + .../public-api-methods.mdx | 89 +++++ .../request-formatting-guide.mdx | 63 +++ .../response-formatting-guide.mdx | 29 ++ .../network-features/account-managment.mdx | 44 +++ .../network-features/balance-rewards.mdx | 20 + .../docs/features/network-features/check.mdx | 26 ++ .../docs/features/network-features/escrow.mdx | 28 ++ .../docs/features/network-features/hooks.mdx | 22 ++ .../docs/features/network-features/offer.mdx | 20 + .../features/network-features/payments.mdx | 46 +++ .../features/network-features/uritoken.mdx | 32 ++ .../br/docs/features/public-nodes-rpc.mdx | 34 ++ .../features/transaction-signing/index.mdx | 65 ++++ .../transaction-signing/transaction-fees.mdx | 56 +++ .../br/docs/features/versioning-process.mdx | 64 +++ .../docs/br/docs/hooks/concepts/chaining.mdx | 47 +++ .../br/docs/hooks/concepts/collect-call.mdx | 27 ++ .../docs/hooks/concepts/compiling-hooks.mdx | 228 +++++++++++ .../docs/hooks/concepts/debugging-hooks.mdx | 70 ++++ .../hooks/concepts/emitted-transactions.mdx | 64 +++ .../hooks/concepts/execution-metadata.mdx | 20 + .../concepts/floating-point-numbers-xfl.mdx | 97 +++++ .../docs/br/docs/hooks/concepts/grants.mdx | 90 +++++ .../docs/br/docs/hooks/concepts/hook-fees.mdx | 64 +++ .../br/docs/hooks/concepts/hookon-field.mdx | 44 +++ .../concepts/introduction/example-usage.mdx | 24 ++ .../hooks/concepts/introduction/index.mdx | 33 ++ .../hooks/concepts/loops-and-guarding.mdx | 90 +++++ .../br/docs/hooks/concepts/namespaces.mdx | 41 ++ .../br/docs/hooks/concepts/parameters.mdx | 57 +++ .../reference-counted-hook-definitions.mdx | 14 + .../hooks/concepts/serialized-objects.mdx | 54 +++ .../hooks/concepts/sethook-transaction.mdx | 314 +++++++++++++++ .../docs/hooks/concepts/slots-and-keylets.mdx | 62 +++ .../docs/hooks/concepts/state-management.mdx | 65 ++++ .../br/docs/hooks/concepts/terminology.mdx | 38 ++ .../docs/hooks/concepts/weak-and-strong.mdx | 242 ++++++++++++ .../docs/hooks/functions/control/accept.mdx | 101 +++++ .../docs/hooks/functions/control/rollback.mdx | 80 ++++ .../developer-defined/cbak-callback.mdx | 91 +++++ .../functions/developer-defined/hook.mdx | 95 +++++ .../functions/emitted-transaction/emit-1.mdx | 111 ++++++ .../functions/emitted-transaction/emit.mdx | 71 ++++ .../emitted-transaction/etxn_burden.mdx | 70 ++++ .../emitted-transaction/etxn_details.mdx | 114 ++++++ .../emitted-transaction/etxn_fee_base.mdx | 99 +++++ .../emitted-transaction/etxn_generation.mdx | 79 ++++ .../emitted-transaction/etxn_nonce.mdx | 100 +++++ .../emitted-transaction/etxn_reserve.mdx | 98 +++++ .../hooks/functions/float/float_compare.mdx | 128 ++++++ .../hooks/functions/float/float_divide.mdx | 103 +++++ .../hooks/functions/float/float_exponent.mdx | 77 ++++ .../docs/hooks/functions/float/float_int.mdx | 117 ++++++ .../hooks/functions/float/float_invert.mdx | 102 +++++ .../docs/hooks/functions/float/float_log.mdx | 112 ++++++ .../hooks/functions/float/float_mantissa.mdx | 103 +++++ .../hooks/functions/float/float_mulratio.mdx | 124 ++++++ .../hooks/functions/float/float_multiply.mdx | 117 ++++++ .../hooks/functions/float/float_negate.mdx | 110 ++++++ .../docs/hooks/functions/float/float_one.mdx | 83 ++++ .../docs/hooks/functions/float/float_root.mdx | 117 ++++++ .../docs/hooks/functions/float/float_set.mdx | 120 ++++++ .../docs/hooks/functions/float/float_sign.mdx | 102 +++++ .../docs/hooks/functions/float/float_sto.mdx | 139 +++++++ .../hooks/functions/float/float_sto_set.mdx | 110 ++++++ .../docs/hooks/functions/float/float_sum.mdx | 113 ++++++ .../functions/hook-context/hook_account.mdx | 94 +++++ .../functions/hook-context/hook_again.mdx | 57 +++ .../functions/hook-context/hook_hash.mdx | 91 +++++ .../functions/hook-context/hook_param.mdx | 110 ++++++ .../functions/hook-context/hook_param_set.mdx | 121 ++++++ .../hooks/functions/hook-context/hook_pos.mdx | 60 +++ .../functions/hook-context/hook_skip.mdx | 101 +++++ .../docs/hooks/functions/ledger/fee_base.mdx | 73 ++++ .../hooks/functions/ledger/ledger_keylet.mdx | 124 ++++++ .../functions/ledger/ledger_last_hash.mdx | 98 +++++ .../functions/ledger/ledger_last_time.mdx | 79 ++++ .../hooks/functions/ledger/ledger_nonce.mdx | 104 +++++ .../hooks/functions/ledger/ledger_seq.mdx | 73 ++++ .../originating-transaction/meta_slot.mdx | 83 ++++ .../originating-transaction/otxn_burden.mdx | 78 ++++ .../originating-transaction/otxn_field.mdx | 103 +++++ .../otxn_generation.mdx | 78 ++++ .../originating-transaction/otxn_id.mdx | 98 +++++ .../originating-transaction/otxn_json.mdx | 53 +++ .../originating-transaction/otxn_param.mdx | 102 +++++ .../originating-transaction/otxn_slot.mdx | 83 ++++ .../originating-transaction/otxn_type.mdx | 110 ++++++ .../overview/hook-api-conventions.mdx | 69 ++++ .../hooks/functions/overview/return-codes.mdx | 65 ++++ .../functions/serialization/sto_emplace.mdx | 142 +++++++ .../functions/serialization/sto_erase.mdx | 128 ++++++ .../functions/serialization/sto_from_json.mdx | 73 ++++ .../functions/serialization/sto_subarray.mdx | 157 ++++++++ .../functions/serialization/sto_subfield.mdx | 158 ++++++++ .../functions/serialization/sto_to_json.mdx | 75 ++++ .../functions/serialization/sto_validate.mdx | 117 ++++++ .../br/docs/hooks/functions/slot/slot.mdx | 104 +++++ .../docs/hooks/functions/slot/slot_clear.mdx | 82 ++++ .../docs/hooks/functions/slot/slot_count.mdx | 83 ++++ .../docs/hooks/functions/slot/slot_float.mdx | 94 +++++ .../br/docs/hooks/functions/slot/slot_set.mdx | 105 +++++ .../docs/hooks/functions/slot/slot_size.mdx | 90 +++++ .../hooks/functions/slot/slot_subarray.mdx | 107 +++++ .../hooks/functions/slot/slot_subfield.mdx | 105 +++++ .../docs/hooks/functions/slot/slot_type.mdx | 98 +++++ .../docs/hooks/functions/slot/xpop_slot.mdx | 89 +++++ .../br/docs/hooks/functions/state/state.mdx | 108 ++++++ .../hooks/functions/state/state_foreign.mdx | 129 +++++++ .../functions/state/state_foreign_set.mdx | 127 ++++++ .../docs/hooks/functions/state/state_set.mdx | 119 ++++++ .../hooks/functions/trace-debug/trace.mdx | 99 +++++ .../functions/trace-debug/trace_float.mdx | 63 +++ .../hooks/functions/trace-debug/trace_num.mdx | 63 +++ .../hooks/functions/utilities/util_accid.mdx | 110 ++++++ .../hooks/functions/utilities/util_keylet.mdx | 148 +++++++ .../hooks/functions/utilities/util_raddr.mdx | 106 +++++ .../functions/utilities/util_sha512h.mdx | 98 +++++ .../hooks/functions/utilities/util_verify.mdx | 96 +++++ .../functions/websocket-apis/account_info.mdx | 44 +++ .../websocket-apis/account_namespace.mdx | 64 +++ src/content/docs/br/docs/hooks/index.mdx | 81 ++++ src/content/docs/br/docs/index.mdx | 28 ++ .../infrastructure/advanced-configuration.mdx | 57 +++ .../infrastructure/build-xahaud/index.mdx | 45 +++ .../infrastructure/build-xahaud/linux.mdx | 365 ++++++++++++++++++ .../infrastructure/build-xahaud/macos.mdx | 9 + .../infrastructure/enabling-validation.mdx | 51 +++ .../docs/br/docs/infrastructure/identity.mdx | 179 +++++++++ .../docs/infrastructure/installing-xahaud.mdx | 214 ++++++++++ .../br/docs/infrastructure/interacting.mdx | 55 +++ .../infrastructure/system-requirements.mdx | 24 ++ .../docs/infrastructure/updating-xahaud.mdx | 49 +++ .../docs/protocol-reference/binary-format.mdx | 302 +++++++++++++++ .../data-types/base-58-encodings.mdx | 24 ++ .../data-types/currency-formats.mdx | 117 ++++++ .../protocol-reference/data-types/index.mdx | 86 +++++ .../protocol-reference/ledger-data/index.mdx | 31 ++ .../ledger-data/ledger-header.mdx | 31 ++ .../ledger-data/ledger-object-ids.mdx | 21 + .../ledger-objects-types/accountroot.mdx | 83 ++++ .../ledger-objects-types/amendments.mdx | 60 +++ .../ledger-objects-types/check.mdx | 58 +++ .../ledger-data/ledger-objects-types/cron.mdx | 57 +++ .../ledger-objects-types/deposit-pre-auth.mdx | 45 +++ .../ledger-objects-types/directory-node.mdx | 96 +++++ .../ledger-objects-types/emitted-txn.mdx | 61 +++ .../ledger-objects-types/escrow.mdx | 67 ++++ .../ledger-objects-types/fee-settings.mdx | 64 +++ .../ledger-objects-types/hook-definition.mdx | 58 +++ .../ledger-objects-types/hook-state.mdx | 42 ++ .../ledger-data/ledger-objects-types/hook.mdx | 57 +++ .../import-vl-sequence.mdx | 36 ++ .../ledger-objects-types/index.mdx | 21 + .../ledger-objects-types/ledger-hashes.mdx | 72 ++++ .../ledger-objects-types/negative-unl.mdx | 53 +++ .../ledger-objects-types/offer.mdx | 68 ++++ .../ledger-objects-types/pay-channel.mdx | 99 +++++ .../ledger-objects-types/ripple-state.mdx | 120 ++++++ .../ledger-objects-types/signers-list.mdx | 98 +++++ .../ledger-objects-types/ticket.mdx | 44 +++ .../ledger-objects-types/unl-report.mdx | 63 +++ .../ledger-objects-types/uritoken.mdx | 59 +++ .../protocol-reference/transactions/index.mdx | 6 + .../pseudo-transaction-types/cron.mdx | 60 +++ .../pseudo-transaction-types/emitfailure.mdx | 4 + .../enableamendment.mdx | 38 ++ .../pseudo-transaction-types/index.mdx | 26 ++ .../pseudo-transaction-types/setfee.mdx | 42 ++ .../pseudo-transaction-types/unlmodify.mdx | 30 ++ .../pseudo-transaction-types/unlreport.mdx | 4 + .../transaction-common-fields.mdx | 167 ++++++++ .../transactions/transaction-metadata.mdx | 175 +++++++++ .../transaction-results/index.mdx | 45 +++ .../transaction-results/tec-codes.mdx | 59 +++ .../transaction-results/tef-codes.mdx | 32 ++ .../transaction-results/tel-codes.mdx | 28 ++ .../transaction-results/tem-codes.mdx | 46 +++ .../transaction-results/ter-codes.mdx | 22 ++ .../transaction-results/tes-codes.mdx | 11 + .../transaction-types/accountdelete.mdx | 61 +++ .../transaction-types/accountset.mdx | 116 ++++++ .../transaction-types/checkcancel.mdx | 30 ++ .../transaction-types/checkcash.mdx | 38 ++ .../transaction-types/checkcreate.mdx | 44 +++ .../transaction-types/claimreward.mdx | 62 +++ .../transaction-types/clawback.mdx | 52 +++ .../transaction-types/cronset.mdx | 101 +++++ .../transaction-types/depositpreauth.mdx | 45 +++ .../transaction-types/escrowcancel.mdx | 42 ++ .../transaction-types/escrowcreate.mdx | 43 +++ .../transaction-types/escrowfinish.mdx | 53 +++ .../genesismint-emitted-txn.mdx | 57 +++ .../transactions/transaction-types/import.mdx | 64 +++ .../transactions/transaction-types/index.mdx | 12 + .../transactions/transaction-types/invoke.mdx | 40 ++ .../transaction-types/offercancel.mdx | 44 +++ .../transaction-types/offercreate.mdx | 68 ++++ .../transaction-types/payment.mdx | 113 ++++++ .../transaction-types/paymentchannelclaim.mdx | 60 +++ .../paymentchannelcreate.mdx | 40 ++ .../transaction-types/paymentchannelfund.mdx | 46 +++ .../transactions/transaction-types/remit.mdx | 119 ++++++ .../transaction-types/sethook.mdx | 364 +++++++++++++++++ .../transaction-types/setregularkey.mdx | 33 ++ .../transaction-types/setremarks.mdx | 92 +++++ .../transaction-types/signerlistset.mdx | 55 +++ .../transaction-types/ticketcreate.mdx | 39 ++ .../transaction-types/trustset.mdx | 65 ++++ .../transaction-types/uritokenburn.mdx | 38 ++ .../transaction-types/uritokenbuy.mdx | 48 +++ .../uritokencancelselloffer.mdx | 34 ++ .../uritokencreateselloffer.mdx | 47 +++ .../transaction-types/uritokenmint.mdx | 59 +++ .../docs/br/docs/resources/media-kit.mdx | 5 + .../docs/br/docs/resources/whitepaper.mdx | 193 +++++++++ src/content/docs/br/docs/support/help-us.mdx | 11 + .../docs/br/docs/what-is-different.mdx | 81 ++++ src/i18n/fraudReportTranslations.ts | 104 ++++- src/i18n/indexTranslations.ts | 33 ++ src/pages/br/about.mdx | 57 +++ src/pages/br/connect.mdx | 210 ++++++++++ src/pages/br/contest.mdx | 251 ++++++++++++ src/pages/br/ecosystem.mdx | 172 +++++++++ src/pages/br/features.mdx | 96 +++++ src/pages/br/fraud-report.astro | 5 + src/pages/br/index.mdx | 3 + src/pages/br/privacy-policy.mdx | 105 +++++ src/pages/br/roadmap.mdx | 70 ++++ src/plugins/remarkGlobalReferences.ts | 88 ++--- 247 files changed, 19478 insertions(+), 59 deletions(-) create mode 100644 src/content/docs/br/docs/assets/image.png create mode 100644 src/content/docs/br/docs/compliance/responsible-disclosure.mdx create mode 100644 src/content/docs/br/docs/compliance/security-audit.mdx create mode 100644 src/content/docs/br/docs/data-apis/index.mdx create mode 100644 src/content/docs/br/docs/features/amendments.mdx create mode 100644 src/content/docs/br/docs/features/balance-adjustments.mdx create mode 100644 src/content/docs/br/docs/features/burn-2-mint.mdx create mode 100644 src/content/docs/br/docs/features/developer-tooling/client-libraries.mdx create mode 100644 src/content/docs/br/docs/features/developer-tooling/curated-tooling.mdx create mode 100644 src/content/docs/br/docs/features/developer-tooling/developer-tricks.mdx create mode 100644 src/content/docs/br/docs/features/faucet-and-explorer.mdx create mode 100644 src/content/docs/br/docs/features/governance-game.mdx create mode 100644 src/content/docs/br/docs/features/http-websocket-apis/admin-api-methods.mdx create mode 100644 src/content/docs/br/docs/features/http-websocket-apis/considerations.mdx create mode 100644 src/content/docs/br/docs/features/http-websocket-apis/public-api-methods.mdx create mode 100644 src/content/docs/br/docs/features/http-websocket-apis/request-formatting-guide.mdx create mode 100644 src/content/docs/br/docs/features/http-websocket-apis/response-formatting-guide.mdx create mode 100644 src/content/docs/br/docs/features/network-features/account-managment.mdx create mode 100644 src/content/docs/br/docs/features/network-features/balance-rewards.mdx create mode 100644 src/content/docs/br/docs/features/network-features/check.mdx create mode 100644 src/content/docs/br/docs/features/network-features/escrow.mdx create mode 100644 src/content/docs/br/docs/features/network-features/hooks.mdx create mode 100644 src/content/docs/br/docs/features/network-features/offer.mdx create mode 100644 src/content/docs/br/docs/features/network-features/payments.mdx create mode 100644 src/content/docs/br/docs/features/network-features/uritoken.mdx create mode 100644 src/content/docs/br/docs/features/public-nodes-rpc.mdx create mode 100644 src/content/docs/br/docs/features/transaction-signing/index.mdx create mode 100644 src/content/docs/br/docs/features/transaction-signing/transaction-fees.mdx create mode 100644 src/content/docs/br/docs/features/versioning-process.mdx create mode 100644 src/content/docs/br/docs/hooks/concepts/chaining.mdx create mode 100644 src/content/docs/br/docs/hooks/concepts/collect-call.mdx create mode 100644 src/content/docs/br/docs/hooks/concepts/compiling-hooks.mdx create mode 100644 src/content/docs/br/docs/hooks/concepts/debugging-hooks.mdx create mode 100644 src/content/docs/br/docs/hooks/concepts/emitted-transactions.mdx create mode 100644 src/content/docs/br/docs/hooks/concepts/execution-metadata.mdx create mode 100644 src/content/docs/br/docs/hooks/concepts/floating-point-numbers-xfl.mdx create mode 100644 src/content/docs/br/docs/hooks/concepts/grants.mdx create mode 100644 src/content/docs/br/docs/hooks/concepts/hook-fees.mdx create mode 100644 src/content/docs/br/docs/hooks/concepts/hookon-field.mdx create mode 100644 src/content/docs/br/docs/hooks/concepts/introduction/example-usage.mdx create mode 100644 src/content/docs/br/docs/hooks/concepts/introduction/index.mdx create mode 100644 src/content/docs/br/docs/hooks/concepts/loops-and-guarding.mdx create mode 100644 src/content/docs/br/docs/hooks/concepts/namespaces.mdx create mode 100644 src/content/docs/br/docs/hooks/concepts/parameters.mdx create mode 100644 src/content/docs/br/docs/hooks/concepts/reference-counted-hook-definitions.mdx create mode 100644 src/content/docs/br/docs/hooks/concepts/serialized-objects.mdx create mode 100644 src/content/docs/br/docs/hooks/concepts/sethook-transaction.mdx create mode 100644 src/content/docs/br/docs/hooks/concepts/slots-and-keylets.mdx create mode 100644 src/content/docs/br/docs/hooks/concepts/state-management.mdx create mode 100644 src/content/docs/br/docs/hooks/concepts/terminology.mdx create mode 100644 src/content/docs/br/docs/hooks/concepts/weak-and-strong.mdx create mode 100644 src/content/docs/br/docs/hooks/functions/control/accept.mdx create mode 100644 src/content/docs/br/docs/hooks/functions/control/rollback.mdx create mode 100644 src/content/docs/br/docs/hooks/functions/developer-defined/cbak-callback.mdx create mode 100644 src/content/docs/br/docs/hooks/functions/developer-defined/hook.mdx create mode 100644 src/content/docs/br/docs/hooks/functions/emitted-transaction/emit-1.mdx create mode 100644 src/content/docs/br/docs/hooks/functions/emitted-transaction/emit.mdx create mode 100644 src/content/docs/br/docs/hooks/functions/emitted-transaction/etxn_burden.mdx create mode 100644 src/content/docs/br/docs/hooks/functions/emitted-transaction/etxn_details.mdx create mode 100644 src/content/docs/br/docs/hooks/functions/emitted-transaction/etxn_fee_base.mdx create mode 100644 src/content/docs/br/docs/hooks/functions/emitted-transaction/etxn_generation.mdx create mode 100644 src/content/docs/br/docs/hooks/functions/emitted-transaction/etxn_nonce.mdx create mode 100644 src/content/docs/br/docs/hooks/functions/emitted-transaction/etxn_reserve.mdx create mode 100644 src/content/docs/br/docs/hooks/functions/float/float_compare.mdx create mode 100644 src/content/docs/br/docs/hooks/functions/float/float_divide.mdx create mode 100644 src/content/docs/br/docs/hooks/functions/float/float_exponent.mdx create mode 100644 src/content/docs/br/docs/hooks/functions/float/float_int.mdx create mode 100644 src/content/docs/br/docs/hooks/functions/float/float_invert.mdx create mode 100644 src/content/docs/br/docs/hooks/functions/float/float_log.mdx create mode 100644 src/content/docs/br/docs/hooks/functions/float/float_mantissa.mdx create mode 100644 src/content/docs/br/docs/hooks/functions/float/float_mulratio.mdx create mode 100644 src/content/docs/br/docs/hooks/functions/float/float_multiply.mdx create mode 100644 src/content/docs/br/docs/hooks/functions/float/float_negate.mdx create mode 100644 src/content/docs/br/docs/hooks/functions/float/float_one.mdx create mode 100644 src/content/docs/br/docs/hooks/functions/float/float_root.mdx create mode 100644 src/content/docs/br/docs/hooks/functions/float/float_set.mdx create mode 100644 src/content/docs/br/docs/hooks/functions/float/float_sign.mdx create mode 100644 src/content/docs/br/docs/hooks/functions/float/float_sto.mdx create mode 100644 src/content/docs/br/docs/hooks/functions/float/float_sto_set.mdx create mode 100644 src/content/docs/br/docs/hooks/functions/float/float_sum.mdx create mode 100644 src/content/docs/br/docs/hooks/functions/hook-context/hook_account.mdx create mode 100644 src/content/docs/br/docs/hooks/functions/hook-context/hook_again.mdx create mode 100644 src/content/docs/br/docs/hooks/functions/hook-context/hook_hash.mdx create mode 100644 src/content/docs/br/docs/hooks/functions/hook-context/hook_param.mdx create mode 100644 src/content/docs/br/docs/hooks/functions/hook-context/hook_param_set.mdx create mode 100644 src/content/docs/br/docs/hooks/functions/hook-context/hook_pos.mdx create mode 100644 src/content/docs/br/docs/hooks/functions/hook-context/hook_skip.mdx create mode 100644 src/content/docs/br/docs/hooks/functions/ledger/fee_base.mdx create mode 100644 src/content/docs/br/docs/hooks/functions/ledger/ledger_keylet.mdx create mode 100644 src/content/docs/br/docs/hooks/functions/ledger/ledger_last_hash.mdx create mode 100644 src/content/docs/br/docs/hooks/functions/ledger/ledger_last_time.mdx create mode 100644 src/content/docs/br/docs/hooks/functions/ledger/ledger_nonce.mdx create mode 100644 src/content/docs/br/docs/hooks/functions/ledger/ledger_seq.mdx create mode 100644 src/content/docs/br/docs/hooks/functions/originating-transaction/meta_slot.mdx create mode 100644 src/content/docs/br/docs/hooks/functions/originating-transaction/otxn_burden.mdx create mode 100644 src/content/docs/br/docs/hooks/functions/originating-transaction/otxn_field.mdx create mode 100644 src/content/docs/br/docs/hooks/functions/originating-transaction/otxn_generation.mdx create mode 100644 src/content/docs/br/docs/hooks/functions/originating-transaction/otxn_id.mdx create mode 100644 src/content/docs/br/docs/hooks/functions/originating-transaction/otxn_json.mdx create mode 100644 src/content/docs/br/docs/hooks/functions/originating-transaction/otxn_param.mdx create mode 100644 src/content/docs/br/docs/hooks/functions/originating-transaction/otxn_slot.mdx create mode 100644 src/content/docs/br/docs/hooks/functions/originating-transaction/otxn_type.mdx create mode 100644 src/content/docs/br/docs/hooks/functions/overview/hook-api-conventions.mdx create mode 100644 src/content/docs/br/docs/hooks/functions/overview/return-codes.mdx create mode 100644 src/content/docs/br/docs/hooks/functions/serialization/sto_emplace.mdx create mode 100644 src/content/docs/br/docs/hooks/functions/serialization/sto_erase.mdx create mode 100644 src/content/docs/br/docs/hooks/functions/serialization/sto_from_json.mdx create mode 100644 src/content/docs/br/docs/hooks/functions/serialization/sto_subarray.mdx create mode 100644 src/content/docs/br/docs/hooks/functions/serialization/sto_subfield.mdx create mode 100644 src/content/docs/br/docs/hooks/functions/serialization/sto_to_json.mdx create mode 100644 src/content/docs/br/docs/hooks/functions/serialization/sto_validate.mdx create mode 100644 src/content/docs/br/docs/hooks/functions/slot/slot.mdx create mode 100644 src/content/docs/br/docs/hooks/functions/slot/slot_clear.mdx create mode 100644 src/content/docs/br/docs/hooks/functions/slot/slot_count.mdx create mode 100644 src/content/docs/br/docs/hooks/functions/slot/slot_float.mdx create mode 100644 src/content/docs/br/docs/hooks/functions/slot/slot_set.mdx create mode 100644 src/content/docs/br/docs/hooks/functions/slot/slot_size.mdx create mode 100644 src/content/docs/br/docs/hooks/functions/slot/slot_subarray.mdx create mode 100644 src/content/docs/br/docs/hooks/functions/slot/slot_subfield.mdx create mode 100644 src/content/docs/br/docs/hooks/functions/slot/slot_type.mdx create mode 100644 src/content/docs/br/docs/hooks/functions/slot/xpop_slot.mdx create mode 100644 src/content/docs/br/docs/hooks/functions/state/state.mdx create mode 100644 src/content/docs/br/docs/hooks/functions/state/state_foreign.mdx create mode 100644 src/content/docs/br/docs/hooks/functions/state/state_foreign_set.mdx create mode 100644 src/content/docs/br/docs/hooks/functions/state/state_set.mdx create mode 100644 src/content/docs/br/docs/hooks/functions/trace-debug/trace.mdx create mode 100644 src/content/docs/br/docs/hooks/functions/trace-debug/trace_float.mdx create mode 100644 src/content/docs/br/docs/hooks/functions/trace-debug/trace_num.mdx create mode 100644 src/content/docs/br/docs/hooks/functions/utilities/util_accid.mdx create mode 100644 src/content/docs/br/docs/hooks/functions/utilities/util_keylet.mdx create mode 100644 src/content/docs/br/docs/hooks/functions/utilities/util_raddr.mdx create mode 100644 src/content/docs/br/docs/hooks/functions/utilities/util_sha512h.mdx create mode 100644 src/content/docs/br/docs/hooks/functions/utilities/util_verify.mdx create mode 100644 src/content/docs/br/docs/hooks/functions/websocket-apis/account_info.mdx create mode 100644 src/content/docs/br/docs/hooks/functions/websocket-apis/account_namespace.mdx create mode 100644 src/content/docs/br/docs/hooks/index.mdx create mode 100644 src/content/docs/br/docs/index.mdx create mode 100644 src/content/docs/br/docs/infrastructure/advanced-configuration.mdx create mode 100644 src/content/docs/br/docs/infrastructure/build-xahaud/index.mdx create mode 100644 src/content/docs/br/docs/infrastructure/build-xahaud/linux.mdx create mode 100644 src/content/docs/br/docs/infrastructure/build-xahaud/macos.mdx create mode 100644 src/content/docs/br/docs/infrastructure/enabling-validation.mdx create mode 100644 src/content/docs/br/docs/infrastructure/identity.mdx create mode 100644 src/content/docs/br/docs/infrastructure/installing-xahaud.mdx create mode 100644 src/content/docs/br/docs/infrastructure/interacting.mdx create mode 100644 src/content/docs/br/docs/infrastructure/system-requirements.mdx create mode 100644 src/content/docs/br/docs/infrastructure/updating-xahaud.mdx create mode 100644 src/content/docs/br/docs/protocol-reference/binary-format.mdx create mode 100644 src/content/docs/br/docs/protocol-reference/data-types/base-58-encodings.mdx create mode 100644 src/content/docs/br/docs/protocol-reference/data-types/currency-formats.mdx create mode 100644 src/content/docs/br/docs/protocol-reference/data-types/index.mdx create mode 100644 src/content/docs/br/docs/protocol-reference/ledger-data/index.mdx create mode 100644 src/content/docs/br/docs/protocol-reference/ledger-data/ledger-header.mdx create mode 100644 src/content/docs/br/docs/protocol-reference/ledger-data/ledger-object-ids.mdx create mode 100644 src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/accountroot.mdx create mode 100644 src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/amendments.mdx create mode 100644 src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/check.mdx create mode 100644 src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/cron.mdx create mode 100644 src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/deposit-pre-auth.mdx create mode 100644 src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/directory-node.mdx create mode 100644 src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/emitted-txn.mdx create mode 100644 src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/escrow.mdx create mode 100644 src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/fee-settings.mdx create mode 100644 src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/hook-definition.mdx create mode 100644 src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/hook-state.mdx create mode 100644 src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/hook.mdx create mode 100644 src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/import-vl-sequence.mdx create mode 100644 src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/index.mdx create mode 100644 src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/ledger-hashes.mdx create mode 100644 src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/negative-unl.mdx create mode 100644 src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/offer.mdx create mode 100644 src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/pay-channel.mdx create mode 100644 src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/ripple-state.mdx create mode 100644 src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/signers-list.mdx create mode 100644 src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/ticket.mdx create mode 100644 src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/unl-report.mdx create mode 100644 src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/uritoken.mdx create mode 100644 src/content/docs/br/docs/protocol-reference/transactions/index.mdx create mode 100644 src/content/docs/br/docs/protocol-reference/transactions/pseudo-transaction-types/cron.mdx create mode 100644 src/content/docs/br/docs/protocol-reference/transactions/pseudo-transaction-types/emitfailure.mdx create mode 100644 src/content/docs/br/docs/protocol-reference/transactions/pseudo-transaction-types/enableamendment.mdx create mode 100644 src/content/docs/br/docs/protocol-reference/transactions/pseudo-transaction-types/index.mdx create mode 100644 src/content/docs/br/docs/protocol-reference/transactions/pseudo-transaction-types/setfee.mdx create mode 100644 src/content/docs/br/docs/protocol-reference/transactions/pseudo-transaction-types/unlmodify.mdx create mode 100644 src/content/docs/br/docs/protocol-reference/transactions/pseudo-transaction-types/unlreport.mdx create mode 100644 src/content/docs/br/docs/protocol-reference/transactions/transaction-common-fields.mdx create mode 100644 src/content/docs/br/docs/protocol-reference/transactions/transaction-metadata.mdx create mode 100644 src/content/docs/br/docs/protocol-reference/transactions/transaction-results/index.mdx create mode 100644 src/content/docs/br/docs/protocol-reference/transactions/transaction-results/tec-codes.mdx create mode 100644 src/content/docs/br/docs/protocol-reference/transactions/transaction-results/tef-codes.mdx create mode 100644 src/content/docs/br/docs/protocol-reference/transactions/transaction-results/tel-codes.mdx create mode 100644 src/content/docs/br/docs/protocol-reference/transactions/transaction-results/tem-codes.mdx create mode 100644 src/content/docs/br/docs/protocol-reference/transactions/transaction-results/ter-codes.mdx create mode 100644 src/content/docs/br/docs/protocol-reference/transactions/transaction-results/tes-codes.mdx create mode 100644 src/content/docs/br/docs/protocol-reference/transactions/transaction-types/accountdelete.mdx create mode 100644 src/content/docs/br/docs/protocol-reference/transactions/transaction-types/accountset.mdx create mode 100644 src/content/docs/br/docs/protocol-reference/transactions/transaction-types/checkcancel.mdx create mode 100644 src/content/docs/br/docs/protocol-reference/transactions/transaction-types/checkcash.mdx create mode 100644 src/content/docs/br/docs/protocol-reference/transactions/transaction-types/checkcreate.mdx create mode 100644 src/content/docs/br/docs/protocol-reference/transactions/transaction-types/claimreward.mdx create mode 100644 src/content/docs/br/docs/protocol-reference/transactions/transaction-types/clawback.mdx create mode 100644 src/content/docs/br/docs/protocol-reference/transactions/transaction-types/cronset.mdx create mode 100644 src/content/docs/br/docs/protocol-reference/transactions/transaction-types/depositpreauth.mdx create mode 100644 src/content/docs/br/docs/protocol-reference/transactions/transaction-types/escrowcancel.mdx create mode 100644 src/content/docs/br/docs/protocol-reference/transactions/transaction-types/escrowcreate.mdx create mode 100644 src/content/docs/br/docs/protocol-reference/transactions/transaction-types/escrowfinish.mdx create mode 100644 src/content/docs/br/docs/protocol-reference/transactions/transaction-types/genesismint-emitted-txn.mdx create mode 100644 src/content/docs/br/docs/protocol-reference/transactions/transaction-types/import.mdx create mode 100644 src/content/docs/br/docs/protocol-reference/transactions/transaction-types/index.mdx create mode 100644 src/content/docs/br/docs/protocol-reference/transactions/transaction-types/invoke.mdx create mode 100644 src/content/docs/br/docs/protocol-reference/transactions/transaction-types/offercancel.mdx create mode 100644 src/content/docs/br/docs/protocol-reference/transactions/transaction-types/offercreate.mdx create mode 100644 src/content/docs/br/docs/protocol-reference/transactions/transaction-types/payment.mdx create mode 100644 src/content/docs/br/docs/protocol-reference/transactions/transaction-types/paymentchannelclaim.mdx create mode 100644 src/content/docs/br/docs/protocol-reference/transactions/transaction-types/paymentchannelcreate.mdx create mode 100644 src/content/docs/br/docs/protocol-reference/transactions/transaction-types/paymentchannelfund.mdx create mode 100644 src/content/docs/br/docs/protocol-reference/transactions/transaction-types/remit.mdx create mode 100644 src/content/docs/br/docs/protocol-reference/transactions/transaction-types/sethook.mdx create mode 100644 src/content/docs/br/docs/protocol-reference/transactions/transaction-types/setregularkey.mdx create mode 100644 src/content/docs/br/docs/protocol-reference/transactions/transaction-types/setremarks.mdx create mode 100644 src/content/docs/br/docs/protocol-reference/transactions/transaction-types/signerlistset.mdx create mode 100644 src/content/docs/br/docs/protocol-reference/transactions/transaction-types/ticketcreate.mdx create mode 100644 src/content/docs/br/docs/protocol-reference/transactions/transaction-types/trustset.mdx create mode 100644 src/content/docs/br/docs/protocol-reference/transactions/transaction-types/uritokenburn.mdx create mode 100644 src/content/docs/br/docs/protocol-reference/transactions/transaction-types/uritokenbuy.mdx create mode 100644 src/content/docs/br/docs/protocol-reference/transactions/transaction-types/uritokencancelselloffer.mdx create mode 100644 src/content/docs/br/docs/protocol-reference/transactions/transaction-types/uritokencreateselloffer.mdx create mode 100644 src/content/docs/br/docs/protocol-reference/transactions/transaction-types/uritokenmint.mdx create mode 100644 src/content/docs/br/docs/resources/media-kit.mdx create mode 100644 src/content/docs/br/docs/resources/whitepaper.mdx create mode 100644 src/content/docs/br/docs/support/help-us.mdx create mode 100644 src/content/docs/br/docs/what-is-different.mdx create mode 100644 src/pages/br/about.mdx create mode 100644 src/pages/br/connect.mdx create mode 100644 src/pages/br/contest.mdx create mode 100644 src/pages/br/ecosystem.mdx create mode 100644 src/pages/br/features.mdx create mode 100644 src/pages/br/fraud-report.astro create mode 100644 src/pages/br/index.mdx create mode 100644 src/pages/br/privacy-policy.mdx create mode 100644 src/pages/br/roadmap.mdx diff --git a/astro.config.mjs b/astro.config.mjs index 83ad662..bde75cc 100644 --- a/astro.config.mjs +++ b/astro.config.mjs @@ -20,6 +20,7 @@ export default defineConfig({ locales: { root: { label: 'English', lang: 'en' }, es: { label: 'Español', lang: 'es' }, + 'br': { label: 'Português (Brasil)', lang: 'br' }, ja: { label: '日本語', lang: 'ja' }, }, tableOfContents: { @@ -75,12 +76,12 @@ export default defineConfig({ sidebar: [ { label: 'Get started', - translations: { es: 'Primeros pasos', ja: 'はじめる' }, + translations: { es: 'Primeros pasos', ja: 'はじめる', 'br': 'Primeiros Passos' }, items: ['docs', 'docs/what-is-different'], }, { label: 'Features', - translations: { es: 'Características', ja: '機能' }, + translations: { es: 'Características', ja: '機能', 'br': 'Recursos' }, items: [ 'docs/features/public-nodes-rpc', 'docs/features/amendments', @@ -89,6 +90,7 @@ export default defineConfig({ translations: { es: 'Firma de Transacciones', ja: 'トランザクション署名', + 'br': 'Assinatura de Transações', }, autogenerate: { directory: 'docs/features/transaction-signing' }, collapsed: true, @@ -98,6 +100,7 @@ export default defineConfig({ translations: { es: 'Herramientas para Desarrolladores', ja: '開発者ツール', + 'br': 'Ferramentas para Desenvolvedores', }, autogenerate: { directory: 'docs/features/developer-tooling' }, collapsed: true, @@ -107,6 +110,7 @@ export default defineConfig({ translations: { es: 'APIs HTTP / WebSocket', ja: 'HTTP / WebSocket API', + 'br': 'APIs HTTP / WebSocket', }, autogenerate: { directory: 'docs/features/http-websocket-apis' }, collapsed: true, @@ -116,6 +120,7 @@ export default defineConfig({ translations: { es: 'Funcionalidades de Red', ja: 'ネットワーク機能', + 'br': 'Funcionalidades da Rede', }, autogenerate: { directory: 'docs/features/network-features' }, collapsed: true, @@ -132,11 +137,12 @@ export default defineConfig({ translations: { es: 'Referencia del Protocolo', ja: 'プロトコルリファレンス', + 'br': 'Referência do Protocolo', }, items: [ { label: 'Transactions', - translations: { es: 'Transacciones', ja: 'トランザクション' }, + translations: { es: 'Transacciones', ja: 'トランザクション', 'br': 'Transações' }, collapsed: true, items: [ 'docs/protocol-reference/transactions', @@ -145,6 +151,7 @@ export default defineConfig({ translations: { es: 'Tipos de Transacción', ja: 'トランザクションタイプ', + 'br': 'Tipos de Transação', }, autogenerate: { directory: @@ -157,6 +164,7 @@ export default defineConfig({ translations: { es: 'Tipos de Pseudotransacción', ja: '擬似トランザクションタイプ', + 'br': 'Tipos de Pseudotransação', }, autogenerate: { directory: @@ -169,6 +177,7 @@ export default defineConfig({ translations: { es: 'Resultados de Transacción', ja: 'トランザクション結果', + 'br': 'Resultados de Transação', }, autogenerate: { directory: @@ -182,7 +191,7 @@ export default defineConfig({ }, { label: 'Ledger Data', - translations: { es: 'Datos del Ledger', ja: 'レジャーデータ' }, + translations: { es: 'Datos del Ledger', ja: 'レジャーデータ', 'br': 'Dados do Ledger' }, collapsed: true, items: [ 'docs/protocol-reference/ledger-data', @@ -191,6 +200,7 @@ export default defineConfig({ translations: { es: 'Tipos de Objetos del Ledger', ja: 'レジャーオブジェクトタイプ', + 'br': 'Tipos de Objetos do Ledger', }, autogenerate: { directory: @@ -204,7 +214,7 @@ export default defineConfig({ }, { label: 'Data Types', - translations: { es: 'Tipos de Datos', ja: 'データ型' }, + translations: { es: 'Tipos de Datos', ja: 'データ型', 'br': 'Tipos de Dados' }, collapsed: true, items: [ 'docs/protocol-reference/data-types', @@ -221,7 +231,7 @@ export default defineConfig({ 'docs/hooks', { label: 'Concepts', - translations: { es: 'Conceptos', ja: 'コンセプト' }, + translations: { es: 'Conceptos', ja: 'コンセプト', 'br': 'Conceitos' }, collapsed: true, items: [ 'docs/hooks/concepts/introduction', @@ -249,12 +259,12 @@ export default defineConfig({ }, { label: 'Functions', - translations: { es: 'Funciones', ja: '関数' }, + translations: { es: 'Funciones', ja: '関数', 'br': 'Funções' }, collapsed: true, items: [ { label: 'Overview', - translations: { es: 'Descripción General', ja: '概要' }, + translations: { es: 'Descripción General', ja: '概要', 'br': 'Visão Geral' }, collapsed: true, autogenerate: { directory: 'docs/hooks/functions/overview' }, }, @@ -263,6 +273,7 @@ export default defineConfig({ translations: { es: 'Definidas por el Desarrollador', ja: '開発者定義', + 'br': 'Definidas pelo Desenvolvedor', }, collapsed: true, autogenerate: { @@ -276,7 +287,7 @@ export default defineConfig({ }, { label: 'Utilities', - translations: { es: 'Utilidades', ja: 'ユーティリティ' }, + translations: { es: 'Utilidades', ja: 'ユーティリティ', 'br': 'Utilitários' }, collapsed: true, autogenerate: { directory: 'docs/hooks/functions/utilities' }, }, @@ -285,6 +296,7 @@ export default defineConfig({ translations: { es: 'Serialización', ja: 'シリアライゼーション', + 'br': 'Serialização', }, collapsed: true, autogenerate: { @@ -296,6 +308,7 @@ export default defineConfig({ translations: { es: 'Transacción Emitida', ja: '発行トランザクション', + 'br': 'Transação Emitida', }, collapsed: true, autogenerate: { @@ -317,6 +330,7 @@ export default defineConfig({ translations: { es: 'Contexto del Hook', ja: 'フックコンテキスト', + 'br': 'Contexto do Hook', }, collapsed: true, autogenerate: { @@ -330,7 +344,7 @@ export default defineConfig({ }, { label: 'State', - translations: { es: 'Estado', ja: '状態' }, + translations: { es: 'Estado', ja: '状態', 'br': 'Estado' }, collapsed: true, autogenerate: { directory: 'docs/hooks/functions/state' }, }, @@ -339,6 +353,7 @@ export default defineConfig({ translations: { es: 'Traza (Debug)', ja: 'トレース（デバッグ）', + 'br': 'Rastreamento (Debug)', }, collapsed: true, autogenerate: { @@ -350,6 +365,7 @@ export default defineConfig({ translations: { es: 'Transacción de Origen', ja: '発信トランザクション', + 'br': 'Transação de Origem', }, collapsed: true, autogenerate: { @@ -373,7 +389,7 @@ export default defineConfig({ }, { label: 'Compliance', - translations: { es: 'Cumplimiento', ja: 'コンプライアンス' }, + translations: { es: 'Cumplimiento', ja: 'コンプライアンス', 'br': 'Conformidade' }, items: [ 'docs/compliance/security-audit', 'docs/compliance/responsible-disclosure', @@ -381,7 +397,7 @@ export default defineConfig({ }, { label: 'Infrastructure', - translations: { es: 'Infraestructura', ja: 'インフラストラクチャ' }, + translations: { es: 'Infraestructura', ja: 'インフラストラクチャ', 'br': 'Infraestrutura' }, items: [ 'docs/infrastructure/system-requirements', 'docs/infrastructure/installing-xahaud', @@ -395,6 +411,7 @@ export default defineConfig({ translations: { es: 'Compilar xahaud (Avanzado)', ja: 'xahaudをビルド（上級）', + 'br': 'Compilar xahaud (Avançado)', }, collapsed: true, items: [ @@ -407,12 +424,12 @@ export default defineConfig({ }, { label: 'Resources', - translations: { es: 'Recursos', ja: 'リソース' }, + translations: { es: 'Recursos', ja: 'リソース', 'br': 'Recursos' }, items: ['docs/resources/whitepaper', 'docs/resources/media-kit'], }, { label: 'Support', - translations: { es: 'Soporte', ja: 'サポート' }, + translations: { es: 'Soporte', ja: 'サポート', 'br': 'Suporte' }, autogenerate: { directory: 'docs/support' }, }, ], diff --git a/src/components/Footer.astro b/src/components/Footer.astro index 05cab37..2ec91a2 100644 --- a/src/components/Footer.astro +++ b/src/components/Footer.astro @@ -65,6 +65,25 @@ events: 'イベント', discord: 'コミュニティDiscord', }, + 'br': { + tagline: 'Este site é open source e está aberto a contribuições', + on: 'em', + about: 'Sobre', + features: 'Recursos', + ecosystem: 'Ecossistema', + roadmap: 'Roadmap', + break: 'Quebre o Xahau', + fraud: 'Denunciar fraude', + media: 'Kit de mídia', + privacy: 'Política de Privacidade', + docs: 'Documentação', + getstarted: 'Começar', + protocol: 'Referência do Protocolo', + infra: 'Infraestrutura', + connect: 'Conectar', + events: 'Eventos', + discord: 'Discord da Comunidade', + } } const t = translations[locale as 'en' | 'es' | 'ja'] || translations.en diff --git a/src/components/Header.jsx b/src/components/Header.jsx index c5c61bd..6be3eb7 100644 --- a/src/components/Header.jsx +++ b/src/components/Header.jsx @@ -25,6 +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: 'ja', label: '日本語' }, ] @@ -57,6 +58,20 @@ const nav = { infra: 'Infraestructura', discord: 'Discord de la Comunidad', }, + 'br': { + about: 'Sobre', + features: 'Recursos', + ecosystem: 'Ecossistema', + roadmap: 'Roteiro', + docs: 'Documentação', + connect: 'Conectar', + explorers: 'Exploradores', + events: 'Eventos', + getstarted: 'Primeiros passos', + protocol: 'Referência de Protocolo', + infra: 'Infraestrutura', + discord: 'Discord da Comunidade', + }, ja: { about: 'Xahauについて', features: '機能', diff --git a/src/content/docs/br/docs/assets/image.png b/src/content/docs/br/docs/assets/image.png new file mode 100644 index 0000000000000000000000000000000000000000..fe3a60ce460809441acd43bd6b1110d822f006b5 GIT binary patch literal 100415 zcmV)oK%BpcP)4Tx07!|Imj_f+=@Nkddv7`kEg=*sp*QI*fRqqg00rq_BP0Pr2{8~8Seyzg0+1%kl!W?uF`{E)8TbK!1F8T9CII2`GQ_NqkRX7{wEeq$=myY)y=yU% z>)(I>ucE{kWbgohLQsz9XYkTcK7;B@o>-Cz0J0zT>o3a`PjCy$Gzr=u$`2+uaf*j0 zIDV2bU@|5=l#MbC00NoIl_UZ{W}tpX7B3OaL-s`3TErKMP!^-?o|cx*NBJbmCTI-m zBTwXK#{VTx;@@({%W`tLi87wr%cKyzg&E>h?u!5OIR3Y!rAnu37@fOlcfF;)6C0Y$4)b!>m4Xtn>sIOniGV+99f=BPWUtnGJL|O zS&|+qtCb*Ov!;r_C{b7%S&h*&c@Good^@de&KGcggecyXqetd=-6L>4bd z^^^HCvchC*Gtn1vW^IV<43oJ5A=3=lARVNlDgg`-gg$u#kSSQ6Ik6FTx_E^|n3$Bw zV4*imz~G2@ma`eQ*0y#4Ox)M0*Wn#~@*YC;n=`(grvSLcjE|3>pYa8u=W%8b0MhV` z&$t=@%0&RKZ{$fOSyR5ryMzTKpa5t<9cTl6^#8yD*aAo33Os=i2mrw#9K?XdfCrL5 z8ru0XunMdPd7uDn1v@}F*ar@Rqu>NM1?s_ha2Z?!w?I4S0*^rt=m)RB2>1ZTAPB-k z6o?9`LpqQlWDeOvOvoMbfr6k=C=fYdyGPn{x4%fk#;ahMQ+ylRY zM-hO?A#_9+u|Svz8wo~Ykpx77tU>aTQlt{8K^l=(K3?rX0I1ClTz*t~hG5(kc z3=gvuvj$U$DaRbe)L~jMcQL(~5zKci1*?fQ$GTuS*l27bb{RGgTZ%o5J&V1H?ZWnB zKj3gUI?fp9g!9M6;F57GafP@&xLRBjt^?PH8^z=C>UeX!8$KA%#b@I4@VoHG@t5$O z_W|SVTNTY$V$;rv-$vMl-mlMjZlPi-uDR*72SMD=enQTU8lNXYu zkwUw*B8g?ycSr~GRLqJp6U zOJT7>wnC}GX@xrq!-_;jBSp3%S8dzDC)Som%)lSuqYO~Zl)dXt!YPD)zYG2eD>OSfz z>f6-o)t_o$G|V*SYb?{)t8rChcouDz>nz@^{8^`FJ<^0V%``(bS85*AysbH^rLEQW<587RHFKrmnxPRQG^x zo9>vNv0j8;j$Wo#6ZVjuE8pUYJ*3HL_?-wlHpFnR>O}*#zs*_ zn~ds>294E>ImX$>)y7XuC?*~zOHC?G?wR6DnWibGdraHSU^54^B(n;$JLa&tqq)$0 zk9o&z>}==RqS=+R?^}>9SQc3p)fT;$bju*i9Lsvk*H#8ru~yrxTCKiYJ6NY$AF_UI zqihpklVj6p^VZhPmSey{xl2dcwdhfNO64&NM|93_r5 zjzdlcPH|4Vo$fPf%n)WF^SU$E*~@vY^LgjbE{-mlE~i}nbhU6zaXscbILCO7V9udA zeQtVgT(<*mJ?;$mIQRYTJs!FqT#rhR=brkWe9yz411wWkGV3_&wU@P*#OtirN45)l zHM_|h@%Ho1_ipo1_KEN*_j%^4=bPwT?K|S<;J4DR$sg+<=)cYXK1Ykg<5Y1*0-OR? z2ebr|1H%H#1D^+(1xbP$=fZOX=5C++WS-$X(Y*R#5X=eQ9{e=KIAm$aFY|HpL*`e^ ze-UaEx+=6aj2gBi>{!@`aIf&9@W&A*5z>g}NQKCSkyVi&qr9Vvqk5vPqE|=XiqVJ> z#x%s@VE=zYT9gze|4rf3a zi!vHAY3N{dTWTWRDDBO1&#K7!v@CMj>E%kxMayrmFk7*C#Xz=i_D?G@D|suMSLv== zzp8gNYxRLO(3-w?H-F;^>hU2fk-zm3&- z@_CZH`%YGc+lCY(%$gybe zR@_$6*6wW{+m0416=xUsZJ)cnu7pvNU-Ev(k{vfn?MwIVB<+;$>?sQ>YuIJ5YwNDB z}RfjbW7aaa}M0BL*Xz0RdYN^A*P|@T)?^JM%Tu(zgYfq zzE{6z{Qk8+_XXue>445a)u8R*`61t-_LmD@_P-Lp8XM00L+Ov* zuT5T``P1{y+au8<{cj|1#@`mcQ-62lz5V;<(U8$+AJRUIea!!){^{sv=I7QgQC|ke zmVL#4E&FErt?_%{_b20N`r3g3bvs08rb}`C-A-JUuDU)HlE+ zf&au)Gxwx80#JjRiLr>?1i(pDjn<*L(dUVgDBKgkc6KtIo_#0h^a;VCUo88*C+Ok! zU@`cIOwI6r>HD7+Ok}kO|Fr)C&Tt29u7Ghv0000uWmrjOO-%qQ0000800D<-00aO4 z0096102%-Q00002paK8{000010003ZpaTE|000010003R00000lC*Kl9cz%>m>1J{b#H9xqffwx@)*NWNOuHtJ1 zu4&*}F}vmi*EI09Yv5Wjd)rlfjleYxTq|bReBhb}-gXUKD`s!Iimws4rh#k4?3xc; z)4+hgF5Z!^vRf1&?jX*ju5+W?yiJkL&qCxOpR=jtlACMtf-vs-QB0hWlbCl` zwm8t0h36rO`&NV?;vpV@(W@}TY*A`)q7nY32I4#~HSZO|$2p9LuQ2=D1m@1aRDPCL z%wRntb8zrv-_&TKSe#AFR;9~uj?tOPlx-^^rZ!WNFBT>W)6~|H!1x5&qem+K`drmW zej*-Om#rMik4G>bAP-o$XH%)=mCeg*+Qo*&T*|TCnWhW*BSU9;r$)#Nxw>q{)a=Y; zA#YqIollsYDb9jFn@YEr*RQVYf@q}2D3CAAoESNOZepOVyl!<(ds(I|N{YjuAL}_Y z);C_521i9YmrkZe@{?BDQB<)qorCkK**x`iDw$}=Rd1|co=IgKRdhG0i)Y7rj*oWN zWXjjpcGTpm<5VKj-Q)cyN4v)gQ&hB>WU3}x(LX(ER*<5JNvBd%g&CxS6U1Lx(_WLS za^)D6tG_u9GqW>ChR*g(4f6;tWQ<$fc|Z@tGZW4g06gYWnW5=%Sn|dnKFMoVP{V^1 z>+8CzvX!!O*wh06HXcupTsS?}hj+P4aG!V0b0M{0fVa4F|_^I)}GJMGLqtLQcIzKy$NRl&=n4T@%*|OoaffMq3 zDH_1!jSZ`I4IGa&;*r>+P%MyKmdf7JwC-m&-gjrm_QGr-ok}mtzdRt3gw)rMfA8-O zJ$7ciZ>CrrFHGIqwC=*>&}rj}j1;-;^(#(}^^VL;LIU$|ty}&Z+kSLM%f_Hd39;vA zXa3>PV~?NRwR_;irrORAEPuz(Z+=ilQ-`8dRlV7F^e^{*eedAOo~aQuv%0zkQ|%cz zS&=EjV31o~)lB@^iNRbdok^ybS2q6q#`k|{)g9S%*1Z;#=m%!LdE$j{ocjL1cJHU; z-`#QjzrXIGhVt5o76Bm7j&=XZp0B>xbD)2EtWcb-%~o7rxBS_j{pG0~+9n3-HQ92i z1`uM1j`Dgq|HQ`o>&mL}6;L>yP|79zja>8#hoAWR$>$FYpI3dGNJ0gFh|C8MR1+(! zn)eKzA_)R0VR>Z}Rn<#&WbMd5U6|m@G`URWwv&%4d@)myJ|7COm`ODo&CO zhifUX@2YB6b!&b@WJ^W;vgsB8q6-65W^&dhBth~@|FPns$M0<429C%zBVZ4}XC{?? z>Ehnc9sX`#e!RW1iFgV>$f@6p#uX|?x$rrYNYD=Bh#)^a*8PXOzxX%z{C0J=f-EZc z#@OEeW1l_v?QA-?ysG8Gysht+ZD(NE{wsg|-DDl$2unHa7p z>L__xe!?nTDWRjHzPYRhO}bjdXF5lg8nXh7P;x$Z^khE9$A`)8pkT zX71Guq>jwy-K#H7kN(BJuXk0qZf;oRRiRP1qT3RRnWW{HOkA8Cqy=cHXt2&tf{q!L zJ0}p`#bTP6C>LRVaE0qS^C*o+ zvPAl<$yA&g?d_f%+U&ZcQx+0^OT8_jm>DjqPr54>FcS|rhc2q~L=qjjv#RM&@;^nt z$W$p0lBTRqMcv*;%qG>3_gs?P9F2@ZQW8K)F>H!55EMmKjh@32dp5MR6!jQh(bt#M1tPS*vu5Q9n8DqR{hsmKJ9;f-j}nvu(uAbF)o z6P$Yz-keWyBa4@kq;`(x*L7yN<0ptO8Ug`OO)(0G#!|1P6f;#v;u8TdJmsE(4iAKpe!7@v zlv$ZBgC$&qq=}g+Vyvqmt}qwj85^7N2>X#Z^S5?!1*V2a`~B z4glCGtF-eZ4Ni?#WI(L)Piuf*_D>GOCr|*duj#m_gZ{SkuZ)Xb zJq2hu2=JJ1aC*#JZz2&^1*5zkTl0t#Xf%LFhxo>{O(TiVjC!ziI((WWn<|b;X>{#W z#<(0mMrUk~1He1lDkf$tQkmiW7*t|h3OPJ@M#$5KLt=1xlM%-P<`p;AbkgDWz9KSI zXUgi!s#jFEnI>T}nMo8oDw;Oct@IeDO0^>?V=OR|yQ}RwXWgT7$>hBqH$)&%1pmc} z{?@X3vhqk7qep&zyl-9o3c03RAj%L6Q05u7)|b_Ia{*l}M2ob!u2W5?I3fRRXGMK` zd7bBzT4$!{??q_b=Q^sIes}v%J$CN3v6)FmJNLA2Yp-esW^{V&%xDj79i!8-Ozxv= z-^D=az|a}5TxMqTJre_)>$<3$jaEV<)goO}^*_0Aqxx*6)v@wyr$s|RiTc&+9%`#> zIzQHzO=oUwTz6;3Hh3GJ8aq37acV{#8~l~d)rRUe*C+U?0=Pf0>}J<7@sur`?B*6c zLKQP*=Do{qys>o?DiyF5Cu3yJEh=OALjKgqg^_7Z{EGU_I4(%QtSD#Q(|>ezRckym z)yl@Y<**S(s%{>d9$rz|LfIn{(kQSoSM!0cn_UTjGQlu3J<1#@jR{%dt+lMWP?#B+ zo~SLW0>BN8(VNSv(IJJzNT?y(+OXOM4=EybY@NrpX;n@F|8Q{vuEQyT~)yp z2r!`PpBnz{m;Rc$1T5t4qIA0+0C|bwZqOJ@?hEdH_6z*6ipSgumAX$jy-d6ydU0fYT5WxYu{CytNPiE_m9&AC6X1{@;7>q ze0Kjg(#bp&L1JblrI@j04{#E1>=}c`5m2a5@U1N@!(u$NIVzmAUe& zgeK^?HkMU+;PUtFEgR+mG*r~iizy_FC&w=)lUcNkY-o0MO&jx*fL&fx<`0jKUZ}~A z$UIuso4TuIBeUBl#(G&8z$kR0Zfsb6W~_TSKY<`1#5wR$rq?4L@D-?VcOy~844Vx6 zpI`llW1|-6gz zTb}FQ@0~{Y1bJB|Ta~Mb+yJnq**ZoFC&qfzQYGk&O|PwPWBIN;TgHzVzov@`6xC7L zBKC>tmRP&Vzn7z8eVr+_ix-HV%znck%qieH1e? z0)sy@*rQ*^BYkXocXA6;7ZyT$>OCgZR#%|Cz+~{KkW(}t(#VDw+-_ugY|r2cT1$`^ zxSWhIeL@1jWHesQP#+U!zR@EI+ZC9CKg358g{gD?!lysK(tm^yMHi)!(YjPHoStQ| z%8W+Efw?ga0Ve>Y=XD0aL_=gV#9s` z%;o+#H3Kjj87KlluEh{bL35QLTLk!>h_cPq<6?*|6}Plv=3L`{ z6NM={57gF~WI=Ofs&PxG%n}+t(TiXJ=Ik!cK}>dXQD@LEpDVC5L{AJ`f(=wm0ntH< z&onwY&+g?sV+O_g)S6k=uB^97Ml1>m`Yo#bG)JnLMzAr_L;-_CI>7g|ZmuuWb|gl2 zZaHxtxI4|{XpUY0Ij!LcWc|g9QIk9xTE9x zZ=ZXG!iMZ)`H5Anty`Pc!kmjNa!Hyaw&_Sf=w@Z3DavXzt?K%)nZ^Q1rUC0TYH6!< zfy%{1K-HMBf?Wby5CQ{DBE1zdI0gqXmrml|wAdhY4!JKt@YWHfvhmiiQlI2y;Cn;E z%2xJIFs8J5`E;Uqe!O>m*$P;QM3t0uoMxtnr$^^%J|Kl6jtrk$QQd+q$<|O_LjZXK zKMENFY;8>ktHUG_$DL8o$&m{_(@2%+n&pl+1JE-*fC(GRYVfZubzQYK0pQ5+?}l6z zU2T6<-bAv!tgf}Jh8TL7D{DGFzWzN~`lw9h6{eZlLtx6x@sW#cEJQSFO&>inJovpE zKk?9ra#C?{ z&qvRAKVkX4^(2oBo$IV@1eJR*Odc9Ky|Jc43XfH(^rEk?Uj`o3Yh(K4sj+TWn{Z`n zH-?CEU)z!<#17|MdGNnv0=i87OZnDxyORM&$)u0U1T0pj67fa}n0#?&ZB48DfMa9z zf2HmJ;ITGawWE2%eaml^1DKx>scb85Mij`EiQa3lZqJ4o!@bi@>ST zo^?!tgnilw*aAg7B$v@zh;z%`m33~sFO`_Rsd0^WjOj2p=PH@01~L+GE~-mDEv=Y2 z8Wh2t0anC;sF0{#x@>cXkyovWbD$|EyP1gF(|1hl^I!9-@+7q2l@l>FnX)m~-_6}C zvt{>oY`@Q(HO?=2sZki^STmwp6V2k~5sYgGZ9aMS)qgp&3t#k_l377YI!h?-nrN8? zC>kz29=72D1}an8U%u|cR2lU98S=4xtXh*d#eX{X%=f!}l1(mCpDiEAPkI&xNcVT` zyt`}XriPWjwe81;r^na{!E6U`?6>;z(Wed$pUWjPH#M(+-?Ez;%WHpr^9SC$>?WEr z>gI`=$*&xHc2ECt`lT=lV{rTYg*RX7K1ieLYC%N}Irb0*8=4UlKFgR-&yRblbHT}5 zna(mIS1y~Jq$zuI;P`L7^jTtnWUc(c74NvYbqgb$s9At0+GB$E;p5Mp9q&gc_q1RC z!Iig{HdV^YG-!n3A=W zd1O1-CpW$S-mV=KZuUv3#*7ty?2FgpRBRcC4HQBlL0D`Q?;?Q;qq7l_B;uinAX76; zoe&Hzr^^K5znpsU$@62H~%{|rHR4vy< zT43p+(9XgY!!x923Iw-j<~&3b5WSK=ODkqB(!|X4@v$EKo(=<|vZA-SZY6yKr-xe2 z%hO*v_UxzkJxURhQn>IH>KJQ$C7!MPyt8%lD}BdUC`583+1r1DU3}Y{*8}b<11FMS zoE%75!;MPluTpr}w?>k~nCqlp?>qWm_k6K;YK##PeKW>F?0?5pqwEd0*#gSy?JXPn zrpHb()5ykMGwp_IIxuUhvzpP0t|w3L`po`sc2A8U9c*)Fit_tC`{`Gp0m}2y;WI3h zZE9FmovY;M87V?vJ^J+jb?7l4syusP4;$w{x$*sQ>%0CP?4M44|H#M%cG=ldhnC|} z7@bvonpTn0Pv7Z1?OS&bob)~HNXbITrkaj3Dix?jXwW8o#kJL~Y|h3lh(UYoOlPm) z6Bpi~2|_3Ed48<7v!c1HrqwJWSy08)%+$ljp8edBCz)-hZ13thNVECCireH_=3by; zLbX3X#->X4wtFRrt#{O~xG*^wbs90{{hd2EHLfCGbh(?l`TUNJppLdz)U-R8>}6e9 zl7O)+iHVs!vyoG?Y$hmB-?68OBIjG)B%aBL(FgM5fO#8>U9?fecy`QAaZk_TKi~Ux z-!KjH%+=k}wC4HleN;mLm_d_}u&u*#Au8_YFTM$f|7Ozz$gY>&?82on< zXQ=?^CsDdu%C)p&W+v8Et{NCfATJbg zIA;dLStk z8U5&!u-wFkW~yN>V>qoCTc~weoM(jM(Jz>RJ?0XkVrC=26g~kkFzjw&z2T+qeGf&& zOzl#d?VvAo?`IMmHjs-Qs!yNWeOv2w%!8vYXNl}!gE184#f*4pV+fg#3+=JVhW%dB zn`$3ofPoqJbua)WuO=A)t9%tHwk@6qy9}9>EOJzTvnm5>No=g{%K$F68almd;J&A^ z8Owsuop(KPX4hbTqM@uBZNWV7)L(VkDs&D`Hz*`>8g1&r;u!0d-ormLGnKWa0!L^Q z&XiJ-^I`@n*R}&(`F&}{EW!(~E;%vY#G$(|RegY=DaK=RS=H7CYl>DOaXV3Q!a7Mj z@*_8YP=xKY3Ne-bN;^hT0j`Lcg_G=8n3$QM^F|f!zUas;mthb23}eJ3Kh}A0HIQI4 zxdnD%ztZ$LVfmapiW)KNvI41@82TXzwii2TGSb=*rpVEJ;o>TLi4=}PbKz?PLTzrE z)*6&yc2~1?aVbI4Lr&AIa1OIllzdm>5_bRKE=(j_NC7oK7Q=&p$*#PFDC>~&?@zsa)|~VguuSU;G#GxX+u+E zEw+WtF&Vq6T>Nsn(PJ2WMSp|#@rqzC3FPXV%K#2y5uUa%EAjJ^P)eZYh0tNl!d#vr zBL?_NSn&XAN2;Rmmqq*3$NorweQxV&x_tURq!8c}CnZdC6Ya^Rr9{zqdSk^)F1NI7 z=$#t2)s@un^f;@lZ01mXZ@BPjvaYFaqX}XIzBf=X11AwzG-Xs4v?Lzs@l46MAH?|x zxeNbVS|~CVu=Y|yVq4>CQq&HI3Zj7V!}EwRM^x{?9)s=k^bZT#abKe5GypSxP-6ys zY@689xXLsy$jEjC5E;$zBfz6yC3N#bb0nCTw#Xykm(PJOKrv!0LJ`Xq3x?Ph%@XB} z0&{Xkv2PW)>edV+nD$hf%phT97Nh6@fdSlV$_9j-n0ms3iUCsj>=r{11r0(#)KAL1 z=w)@jP$?bHX2OjPD{Ml=Kj4nJmgN-<-IIgo$NO>a+DzHI+P1Qw%$|urgcw#(7#iJ3 zMY$Fu%sf(DD6xd&Gcondc5Hlrb?R69jpUv%!c>f+;$zso8m`Ic!?jEi@d^;NHWF8A1Vkv*+s!tF9S$XP!^PVVSIo!5@g{e z$RAyI|IU_;24ETN=4{Y~4)*-oT)B_LNYWd*x{HY^m=r1Nrqg-wAHLX8*}#0U@TmNjm?Q!`VJ;0DsM`&*U~qRvU#CZV ze&dC|0w+;SJiM>#CSE^dSLYwx{BL?DhsmC8!1U8iR5U0K2L zN5_mvr*BD%lnr*9xMKE&-RLUQDq5MT!qgw_`J&CipeS`anKWnmq%K#Xjs5nL$k@!x zgRAcNpLnCu91i5XKkDxUkOl3@5v>iO1OL5qyI<=&0+riaw!CxMP7LQIZJv^i9o0Yt zXn~j^%W0gQri5ck92!od;tCA%!ZafDgBH`Llfk@SfXV-$F93wpjD>^YE%MlK3DLnK z7s&DXhQ$f_s3Rsv)}>J@t~f+Kf4S8~6aVulz#VaOd1K$~&|bCD8BR&1D*W4=p+ zv7ks$@YIJ;wZ+gxGphV027jWjOe6{O@dOx|-&65WE_P%r>=M`@h9sxRi)_pYbyPNP z2$q#fe9a4q9f+Ej#GL?IkwI3x$oMyQ;cvd(+x^$a!?_d4Ll2 z^<&Te?U5(g8VcH%x)1bC4}WCMJzmn{dFO?l7F0m1tba3?0g{yJZyX0~1-PvEAd5*P&kWqjc_vp75W68uK~}{WV%_jX zI-g9v5Q%Tm+Oz+IReSn@Z|R_p#qpbDixeUwrJE6jn~3t9K!nQicv_f?C#CzNks}$+;UY_zIOnhMScG5* z+R)vA%{eTx1f!6^qsql`89C$1coixWXAY$+dstdAbE$Dkdg}DNSpZEZbuJpTP;s21 z=BW}okg$w%U(7Ht4WrC`(@Sx7$xgj%c>Ki;!7WrAk-(%9J|&>{$>}TeLKNhr8@s&q zfE+j>K^DLwx-q~ogZ)LV=oc>`yHjRXhZH!sS%jcOlZxBX9pbK3c}$Mt1Pnq!E0vsu zG`ZM75I+@X4zd5fhsta@qJ><^;k*D4BiT(wGily8(NrPZf)=HQbO_77jgPFl<4@oG zCw7@IE5KWM=o37QrVxsZXq)~vd*~3EF${#dC&vHn`uDZlL1q9%PDvox$rW0{_Cw{f zoI0R-A<6z8kXP&VQ*^i}Q*08@1pqpvUkY_~_;D&#B{Bz>XQgcfElI?qc6?6*c87@F zp^G@~NEl0`by#Jd*HI0aWly1vU?TJ3v@tZANQ1IFm1#z3-KpYWR}x;_9+%4L`fV($ zx~pYVbGTgy4l;?^lcVRaFJBiFsAS^s(3yrz#XYTCnD&SiVO26XY*JqJXzJ`l-?sYY z1e_v%&pPQm>P(Ka7rrW6fx+a~w(D%)z=`!b*$O49WHL=ZnV)=j+jXqd&daV=xcEk-;;s^&DhQ67(pyK2vd9(|YHVTtK4V|9Jh6K@NKp&muUl*4AeH zmZe#rlc9yaK<0EVCzP@Sg{{E9}k7l;;^w`C+RPN&yoXJIvskVAzc8ZED!%h!t zqu4CAseU=77gacE?&yI>ru$wv|N7y!i*)uu7Ne%GehTh+QVr50sii$>XLd#Lj zKe&Y>-|~|;H?DCQ;BcF>V}0*z(a{XDpA4#-0}yf;49B^yH&@gJoF@~Uew!}N-rKen zh2T^yX0EJkXt4K{qr5_Q1=rGwnHWqa7=-XjDM#~R6-325?`qxZXCa#S5`|4qBZaBm z{l^(qQ@V&jG-jL`ccL|8OjDHC)h;_SauF}|x`zb(W**yU=g{Z{)>{dn6AaK<(Xgsk z9T=qbjGTtRChJ}O$LJA(mTHOP+-~dCOBrS%)9zfnWc8Z(snb7T)XvGo-dMpP8}`|) zW37|g4LtUjHs1fxn!8~Da-x|iK7IDJ|M}IwX9pI0DMUqk=dwpfF7)_;7FJm<%)kv>UV@)VrXjNN=xS$xEW_DN(&^i>=F8@tYcP zmOzD~NMJtj*wAS~*bEJucUM+6f9CMNP(A@b?NH~v&+f@#6oQwane7d$e|_si6dO)K zjH)m;j0*{3pA=_}KZ~>Ot5eo3n>!*v%X$9ERbc zIXCpp(Ouvt7fNU;uWig#{qyOUshF@Rw0PwLNAlg0z`!bd|JloiSw%6ViP0~dc<%hf z0F|kge~v%W0Y1RQFFM07_MQ}{W*6$Ob=7TnENIE)s-qHQ#nQP%3M%&-8rLkV*6A3L zfE|_1Y$Vy$f0St)s=eh_Tv$ zKjAtw4zLLGNLbM82{vM1s$3S3;BhrmJ+DlAQyGPJr+QKy2{ z8>Gdgou{R+*3l)61^QFS*}N64n6fic%$5JW!&V>5e6w~aPO#TYOwI+IXG z4(Ee?Si<&nz+3|+l?tA-=edEk7Ea>p;W`Y)0h>QpiXpcveU6zpSHXwAh zM0}EwJ=2m`d-O6O!JyV{D_M^HF_co&&WrG%0+`(@R&Yu%gy`r}VvTXxrI^;HKQuuE;gP(CMBWg9nT0{Jr~o1cA@a%6>L<W3!NSz!J_0Q3yfZY6>U_gh=kVMaY$UypqX&E+Y^UT+p(*sfezu^KWYL zpj9gpE%-?^8#%alqF(P#tFr^bP;=tMwIK}~KgNI5WfOp1zH((m!zi+r z5QbnO5}}IXoV_r{o{SSgU>8QwI~&*D*SV9Fs8#Vim%o!e0*I7JjQgY0GXR0P!~swC z$0AK;lgl8DX}f7Ih=7HiPx=?UNqtMRHcYyccoyLafCX)WM=7PieJgIE|E%t!fGmgM zu?Nd$kxr3pxG0Xw(TlxKjxh{Mr{bYY zdv2_kqr6~*hSevIKd|cd_R5B*&b`WBb!Q1)4S}(5-9`G@x3z4b)kX%6$b0YdTh`Pq zo5w%>hYdBIOr=nINkZ@JE;})DVRPdeNl%rWNcK(+P2|UKYudnGIJ657e0yaoKf!(| z+0Zn^!0G77Io>;J?9EmlntLU7Rbn?Oh!2ySZ^K zZvcQNN@9?6UHx(+C_&K-;rqL`I}F_qhI~v9vhOy^LS{Ukv0vD0l|T$uc{d&@95tv= z)JhG|ohki658dN~JL*>ks8l5v`X)zi(J>n;R9rSU%O2u(27VkZv88_HZSB{utnI)B zVMfXeE5`uICH|-~3dLltnL}E^K&yCg;1u7WA(NAXTV_xr4G@nAD6?l`h^fDTE1Rdq zf)8}6bZu4AxK-I)88b^==mfmNb#ms zd#;AfoFqkg=aIhD;}VORxYKs>R|igXO*i`(oj0%E)3JjS_Cy|scH^0Y!1_)*h~`q{ zfpQBufO8*U2=ibAw%hTh7FqzDx`$o49P}r0${+-+E>vVIUhF%}!YdObX1U_oiGgpP z{(jABjOx>EOh#1Pnycx{k9j=`GbG)={N|7y{bd^w z6U|I)^7=i#g4IXzUfH~{)XiEYve42dY{)u`9Ks_h6*zxyt%7YA9M0K zj$6XCcxZ{mEJWf~M1HDGt0ZJOPmDx$?YID8zWIL_nwnhmfq1r9OCVW)7iJ`m1pQPO z5Edf)>6u_qY!s;^0UD|hEXrtUdJ>dlSd5(G5g3hvAyh_r@S;v^5T=cg6Xi4xESKd~ zP7erI>{^@wWe2YkBR(Cg9)&)*K zbRvoYIU{eJE5%z_V@z6t47c~Oq2j5!I%g#@NHp$|!ine^8)M)DG4`QjjpgyZB0 zN4dnX;k3YF^cF!jKk6!rnR6~}&PS-{NITB%Vj!1{TO8#aGIJhch@={>2m^3Ilt)`? zbPKVBe`6U-Fv#~-ijBxcxd<#298REQ?iHt~7JwZd5t4-&<7lIB2=7><=*tBn%;Y5; zVz^wED2;}T3A-0B?x*)fGv)CmF-&z4eovkE7@>*>;QlgTi|`qkGe$WU47f6vybRhn z1M%=85<_0WkO>K0NWU);O_1Gi1WH{hhB&+wRC<;LVvnVS zA9~2G61NR>>ACSa3wqZCplEj0@n#$d#UuTnhz*js9L57tQWPMb<1UyYE5%$^IAJuL z4(}R{?nFlRiXx+cXVK{zfW_-BPgv|8r?psm5NAvUk}e7sakXe_JTl_;%CpSN&Z8so zc=Nv>f)j%6s#`OW7f*q9#YVl;ldn3Amg({b>dX48Y)u z;S=Eu(MW>-{!H9VW`AXkLJ1DC%Gx}>B4HcmR8J&2D-nSmXJNZY)O zYjvJPb29*fKz+Y0`N{jV^ocd$cX1t3z~XziQ|Y(3tE}gQX>E?C>JDRH@N)?K6CE{$7vQeoqViB?KBB2vd$!57B&V7wz8jV z82sS+TR*kw12U)x%Nbs|xc?7d|FVo~S()bI$kfl=@#~z?8Q?PDpL^zy_}n=9C6Wjz z(&CkfDWnZql_`;<6bT?*#w0Z#G)vj513=h#Ml+EAeEhkm&hDmo@apl$*1fl@y5*+! zE&LpzO`j%SzPR^mC!RYvbe5S?P7b}T?Rpd&IiEugOb-9ufp5RkcZA0qo7VA-+`6)w zk8QkAPFnuHzRWeDwJDe$aOmNnM{=j|=4 zDQzl&)n`_6+$v_1zi!|X*sK*S&miwd9F{|(;t<|r;o#eaSM zVOBbSdi{I7d_fL8)KlL+`NF67e}m-^+Od=4{d^$%&+qs(PF#kfaCu{H?*~E4WYKgE zVtQ(HhdvICuDse}8I4vK{1E_VVw?Z|{^S4c%}4kiDyL_&%J;wS`2rts;>cuDC9qv( zNscYa^W|}^2eQVHDAr{v`1CUBj;JCdE+l^-WYeKIn7LWtibSI;y20A~Nj6o#^f0Um|NqzgqbLBx?=;zTjgB{e4!dk2oc*?+9b z4nM{GxZvLY<9!qQVvASs_!eM~pWoBR_jRpdDRy1^>&x zlsl(+6m@Rsd-6IcmL3%@rHX-w9Q_M#Rh^rq+?PNm2A7U8*kU>+3*HcMF1u(yV3^AW+#L;FHM8H>(COC<`2=G;O_L&p~wyhu1C z4$UTAYsbPeXZ?1L!bc&IbOihg7>f*Mz6ehaKs2>XKA)pB&?yu*X) z9j%-F0DW8;055Vd4D*y`V)##g)KhtkE=W^moE)hTbuoiB%J`xm0wIzB!$=J7xknfX zIRBgLSMrS*4%TO{77F2LH_ks~qe&c+xll$X0Z&#Yp$;x{f&kD44=LiI2qCMFf|Ib| z1R$4gWlh_44Xcp6{!EUp%35litC=hl|e_l7-p03#|1OQQhGLk%Kp zFStMgS9Ie@#4dPC1R{i%!*nik{9wb)=i~q;hWM4W?VVLkN6dU!3&y4k`Y`-FtrAbg z;UogzV{*m7{1K0WReNJdP#|aI?CQmJ)kd2S%Lj^bW_Pm5!o<$THS9oA7L~gtTuUfs zaN~&ijPEBl-2b^lkMrIke4`OMJkZ61Y3P7Kr*t-8rdUNMxb%VvVWytV5@J&dP4c0z z2H+#)VCd2TY>^l$+cchadV>gE7nfHz|I)?}sLK$(r~*YwCN*Dcc`cto0j&semccB& z_(_g@L9LAS`KAPO2EVxR{lK5#ec^O&Q%&cGSKq};!Mp@Fnjc547>w$B3&NK`&QXN!wT{Zm zCtn8s*xGk}?c@vo6^s9>^ZVvvLW-E}BJZ17{orKPOK zUm=IYOd-!#d(cdu4!vRDBnQb?G*>k6p>P^ZcA258cPzW*zOI{$A5^VTC4%z^&nT0T z60{gQQ6q5lB^w%T{t{`_E50}}#D}cNVs3}}W-BstY6nA`QO}O|p#^FhIy^{%IgbyYmqj_qAQyK}^~U+E zA!Wb|Djd3=*im&9h~4Mo`N>ta?Nr%BGBw2x zM!>t+PGGMu^S*gX8~=l9$W(HrwjnV7<^^dg=78=MH{{<2xyuKAngyIW?e1$B%l+SGE12mAAz?0kW;K`Fp(w zXsJSSeEzGPdiwN4Kh+^B;ssuop^0S5n~D%F!CVz~1;w;osFX4W5-Nx-wz-}#(&0m{ zZSGurM`Hi*S=Qf3A|FCir1|jD!I5JggLl?vD{rV@`8Xe5vd*Vzpn^$-lViOwjDJy& zJazu{|8&F0?(W)w^SRY9CA8%3VZlal+>Ts)b3OjyC01Yd4V{Arn8RPe|L(Re&(8hC zJKOUE!NNaC%?i!o(Qfb8&|cN3MmAlK1ER;0v@C>UUSs-8% zK6P@2>R_o0Jre-Vr6VR&)T#r8jb$ay>&7r*$%gFAUceIgtINyJjP*U+y_aGJ705}S z3&^=W$bxjZQMe`hZe&;v+~X*`KLgHHsBVBFfSI!u$| zNN4+wI~a{t0O&da3_+k+${!($0t;M-EbxDsEaG0t)`KuS7NaQ9H7A$j*+&uqHDyHf z-a4?fVir&hb%gfe#`su3Sbb?@Is{&n7dKu!X#t{mqQb83d2(VH+=Ut%mM9p2@t=U1 z1e6+i<8$=c*w&z#39~I~yJ(FM@C>4qP3qRA%=W~MGVBeVBEpLpM%8t6`4H2{MLFGv zaFK`;G8sRPGe99KCXPSD62&q|i^W?EYooc?uwHS(?w4iqC&eo|Ot(jzk|UjnLkadN z0*zW(X$8`|TdM4Y(6Slg0KHQXH4B;F1Ex8O2;Q@qWJE{x2+^Pej7Sx70}#)sIv`Y^Vouv;?9VQL@)&%QxC#b;wFHZgqC5tE#0gQ_c{A z=>hT?Im<|wRqD`)%MpUy8xsnimhg>v{k6e{q>wk3#4#@B+)y>2)aWR$XEsvxy*1`A zj90*?D_^sMI&xe?5x0wL0Q}542){fjn1Z8ENQ~39K#8110;}03G(#883n54#gsLNo z#M3mnqOdUXQdQkx;|Q~edd^%NfxfeO{mXqvdBqOAOeR&;baut&>!dY16%Wou(G*A+ z{V-7xaVABX;HXiuU;0|;LJMQ!xuK7)q)o%mJ)ZhQ2`{afIR^-gIi(w$ejwnMa4w0A z7qmoMckTU65EkDw@{lfY{Hi|uzS3pm%%xa&ii!%Ro3M+ zH>loGLs`=YmfgJC=9lQuF(>Ilv8eECTYlurC%#7u2`%_x2L@#MK(iMlCcnMjUtZA& zAuz*gekRW*Cc^pIJYy9;LF%%&I05y!f22%P$8T(X=&uico3BQx;k9FQ`6Oy}8am1V z2h4U-m2^SQt08;MoL0B1qQUH?{vjPU+RWjpQRZEJREF~TSQHgO@P0a|+1WEQO)na? zXsOD`qf#a(A;IB9P7y%f=w-Ai>+_MIY}M-8jt{Q96K3L#Kke{`R^P?$CuS7bw|QON zvX891v#qL`V(F#Dd1De4K7D9SJbYp!CXoD_!*O$an{QKVD%#a^8A|$txXWZ8&~-{801_vG@E!olhB|{ zU!#T@R_cJ3ooJ&9`Tc{Z)K*)GHMPuctY5adeg!d35f5g%5A`}N&QxUFTUTBK8@qdt z9OKZd;_SA@HPia}m`&Z;vZ1M>f#N~c<9Nsp#m^u9?jy&Z<1=fh5oS1) z;il#dKezGyY&V5ZVgLq=LvLT|J$PvF4E2;OX8bw>(S42!S!IWS<; z#Apwk;3W*MIM3tkL_b>%K}1G;h@G;3a{I5)qDFWShbjI)-t(n@KJ^lHGfO%TF1z{n zZu%rMDBGGh@QWbl1=#HSYVVQVgC}TFsb82!SzF!qV$Z?jC%$Lr2ry$h^Wl}Z{^quy zV7$iO;n3_cHZDH^U9bEmrRf3r}l(r?9v!=jPzX{+Z)UMI8-^0 zgMInf(|^A2QD!@l2#qnh%4S!3%Q1)H^o|W2SK;mi46{V%<7isbt zuOlN>Kzl{~f874D_b$H)D)dy*_T|M~YUJ#hS= zPkx_bX5D&Yz_|RD+_)-mV*U*0c@c-4VT(#e|T;QCJb87&8xsGimY2UL*r8OQoE83tjvNpYv%z?pAG6 z8ue1o(DW!=v33M;1SILj3vYh+{GOH7ZJ2@4$V+{PpFH#O2Uow7_R~zF+C~3EYhzs+ zUhu#nzUxgKGV)_4kOc!AOBPP0zH{ak4)eORodc5bB^4?|Gw0?4;_FZsP(Vt59GU&vd~AS9HV-n$_@M#!}Y~H&VH?jX!2BC3`9)h+%9aLcGEg4!e&H zpQmM@+=2lBjC5$|EMZX$r|)@;E*K;1?@b`1(9(1n10?w`MaUOcPase{B8KinT>>`OIk|}E+Y}Ub@_Md9K?ir!FY6ueZ`P)> zQlXvC>eW6kt(Z9#vy+tSTp|@3^oaog&@4u3tf3lAv}ohnQ)KIU_;<_hu#GRUG~L3JLu(`vB`j55iV95QB#)Qn6yGM%p< zW)! zhQV`}2)iGfTL-IH!jnp`scNASWBv&hp`Rw+*GiWWKmsy*F8-n-e&$Q`({!w2jGzm^ zET=ZIF(yah)O<{#x!OS#7pKHiD5H3eDGJO8%TM%@R$rj}@TEq>CT1wF;5VW&uJhxD z0ES&=GDOVH;&d+`zM5jT5F@OpAlW58Y)at6t8PCt*1c!o1a%K)L(y#&^=K{Blu9Gp zSQt*w(~wo|T2s}GPQe#ovq|KhY4!>RrDAK{@}F3951(}g0JIKrxIm>czu>|T@D!6&CRVqT z4>yOW&o2O11Uru~l`LnCgDP0_4~x+zqjZt)PR&$hwATSIUlfT)&J%D^NOOyboQOgK zNCGK7I;5saI>a38eq_dy-V`xxOzkSKXSRbFI?upU@#jrG8-KW^W-Coh-7aF>$RWl)4jCK7DTgE5#Cx8^N5I@^4@ z0Q}Z(Bv6}W|D?o0lU`7X#4d4%A;u$t;DSL?X|a(Glet1*hFU zDk5hH=G=tM*dq`ZXAaO}50^9TV(?L%OA$Sm0&t)PsyK_6)6wE>U)mFrnfm+osTcXC zhPN%aGHT^B;lE^`4hqT@yVUX%r^oxf<|7wUF>?6ihWk)GBq=S-^6hBRti#~c$m@Ma z@QJpHhOM^0CK8@POYeml%b(kL|C-v)GZX#bN8OFNO3pvC?LwN{q{_-BijSXtjf|@5 zu&9Pl6hFWx$ec{BhCF+E4h>9?BHGr*HSl@w@|&x2m2V85qR_IXo!xUtL_b1`BeSg* zqMXs`F(xE=zrKHJ6cfMNdx)+k18FE?1zuS=Idb8VqtEim4y!Aab1Fa1SQBxaEBTC_ zBpYc!0reQQAIKvi%4bYib^NXCKT6p)%On`)Q0l&U>P6mFr}l>#wtmy|`ll1mV>UA- zR?q+y*F`i?HI-GfuXQuCrq=u5?)b0pe$~Ych8Mp~^J-_1YIEaiei7X6-owX7F7SN~ z4IfP18|s!lwDw&Q0D)Z>_kHWkF1077M6`g)KDFtAI1J(QGL^QhR{jHli|U0M9Qe|j9*@jiy8YpPpmz{#jg=Ani}t{`94EQK~JaWLCAPrb}i z6~^<7%!qQ9&Jb%GnX+AR&Me`otowQ>;h74=vG2}IH^0!F@wJ5gV7N&+Vigo&5@ zOE-kI3YvY@;0vtnWriNc=MO*r?NcxFB{vZ5Xj=E{TR+Mh0JpYp<>#o;j|zEM{d;TB zJwEW4Z$7fS{}>;I8nnDDGtih|O-Rvh(zdgS{N?Tg-BZIFkLe>X)3-FPp4N{ zMQr9O2SmL=R>OZ`^9M`t34MR>%SWGSE3fCPYuJu@gk`5kPCUDR=&U#CjF~spc2dmt z4xPrzRD4uVKe6Ur53an`S3ca&<2Wx9zUpEY8PSoeR*NpzDKR*@FGFg0n$I@y<48Y)Z=9?#8_|};pG?&YX&y1XB zp7*BawaaVt5*l?O7d!wDT3i`C{G2Fvr$xY;jw1CsB=qW=4b@m;! zMKi0antAhQI4%5ClG#F@`TdT{#;QE+XL5YD@Wi>@8*96MVao?EUx_k{NcjgjO&R>4 zid0f98tHf3W|=~sZ)K2eAU{q|7@e@f{>7tDY;9b%zJ56+Q-k{} zzLr+Z95MR!IW(tYic^;?A_@Ru0}J-cxS|n~pF67u&?+|OXR{m10v3x2WKb_oWyC&z zOiN8r=TA(Y8SB9pnM*{ERD{fP?(086F%u!n8t@>UYQoTXGp@8ZR{<3>Yx+TI%s`re z+#)VZD3o&X1BO(<$d3Q{UO`}BgYryeOu%av()dS`3Xcd;sf#c_9vv0oSwn>t0p?No z)qDsQ9XV!?V2?#SIs(*La+phBsse1^voxktt)wkyz{#1I+(^+TW@*5cC7gj;3_ZD| z6TwU0(urHmQcJhPgQwZZ5*+55)LWjrdJlgx5O8r;LB}>|j##Hl&)|)&vb|d7-V$Vi zD<`LFTH4UCkULr;JF=KQVO?gGEiB&I3Oy~Nu8}s9l4^zs!eWEf0{UDavn1|r1t0Jcmi zix5Nrk40bd0X$p*xfH6T`f}NrUj_*pA{BW43y8nA-(2}LJkt>g^yaC?YRa_^J3TYQ zEI(CUoG=PfR%>S*xut?YkzBBieT*>`U#AFZT*~$9Ji`*i!61e$FJ^HR0dIy47Uhnb z$<#U|A5h3CC2?oyZ|6KGcK%EH~PjSR)Lp@;VZlsQfXgwy z<$YxUcI*6GG)}QIZ~y8R#gg`mqLqmYo+=S!E`R zsua6$5x&}J)s>XaSb`r4Vzt)+Fh^y!;@+;EPoLX!X1tG5M|JqY zkZRmj83)K0{-I;Q+v)ZixD`D0H>UlhL@!DHn&@hA`!S^HS?BOo> zE8oKYk=1uax!i0{!-I2sLB z{Dj1|szqoCP{im*VIUeSL&DnkB&!-KHI|th1(i3lIL`GOXMVsm19;lY>Ns{1mJlp5 z1ezfnAtx2%?rd7eh8VsfOpj4T!v5hEZYZ8m2wc#fqvV2SM3dMEJUk9gkMf;cRO;~R zBwKR_OLj>)$}ViGF|$Q2S9qHA2Hr%1fz}6>-~72FPho2yc|DYQAe6>t7skT?K#09; z1W=mwQ)Zda;?;Z3cOViwali7b)Nj6$JTd?lvbU9=JO4VdgYAG;6`3_Sd24EmnVos=}$24yD_FZUccICMH< zhAul(XP;RAK8QjcOVcya zZz-!|YprL*w9JL}paGnRT_DzrEw*>UDeZFvayu z3_NxAHTGUoO%uVSF@1HG5KIS}-=ytgMt~6`Ef{l^>;ZaL*AC1_g%aUkg#2PrODkrE zL2MYG33g=C$e0xqyL%4(?cskpH{MUxNZDx4RWnNyeb9)EC<}H?iQKrzDt|_MfzlnaTqV^&5T1KfC`Mz0+E?0~=s)@=IGj_@1sC@hv)Xly=S(_`>1u ze&@^&P=WW&Xhv>oTK7}y?ybyJSZO@l+6kLQo=|8>p-M4qB zrNVD`ZvX%a57hxZG&OsP1Wkv(6Y#>ty`MYy7`rzy!RGp|Pi=azv#JFZd9wosw)y=p zyZ(0X;7NLz6nl6ll^yg0)8pDhlhEs=x3_L#R>qZt^6@-80VauAQ!|lQXNdpOfs3wo~%bsJkMmK_ckHN*aTX%OB8HOfU(-jYJOwe zk1wxo#rxp_3>v;FRbjhSr~JVypF1|%?FC96lStgzw&mBh{kRLrBMfkd6Ye9^V<-m_ zSP;!)4j3STRGK&xDE!F;dSH_i@K;gB$hEXiW2hjEruN;6K1dRSlfz#*_RN##_AvQI zJl!59K)LhAz85WE$V=U+t-}Z@#b|nGMb)MQBNuS}sCrmd+4v^=n52QyMP74L3Aump zG+O@Scl=uo4*96L_aAVPu#Az7$`U7jz3=E(k3DmAw40R{BIyEkRyJs-*hHW8ur-Yd zpFNZPoTG|1ogSn*%IdnON3bjU<&mUyHSMnsoOCAPf$6(-)omwyOD-MYM3OqMqpF#? z>=M(71oOz0kfS3PY01gOuPU9X$yPC-2-d+cry8`>sj=Qk4Yf7d0H3$EZ0f3RCEl^& zA6^0@wnf#VsE~OjEO3Q7qdxJ;pf&@k0t4b5*Ctdc54@-kvYQA}FW7e!d`TwlL} zNkuc3Ua^Dj+A0=E8sUxKqM~_ZWj4oLg_k1u#7U4Mf{z$LfjA*ki=N~g9wIOT^E60C zoX~y1k;H*7A6{B9a|KBNs}CTCN$4H%dI$?*HMwdkIU?1~(BM*U?1!Tl^#rt&l_o|( z6*D}H>;j0j!h~5poX0f49)pnlcy;CY@YywW%cE`p1|y?u7Dz~7_Wi?WSYXwQMw*Ed zEjnay>s%QR!ipIvb#gLudJIGN39d{E@d`zX954iUgpfB`tSOOK?n3RJ(&l6IL1#~3 zT2A0xTbe|5bcM~-;w>0NaVCXlXMD^F42}i{Cqe7PYY+@U-4(oyxqxm0Fd)t=y@#0i zA(cnuLfGBChiK4fTfB=weEb3%qG2hvXmT17%#(K}Q`kRnimCbbswTKKyBI<{q#)FT zjD?bIom~MQX=->GieeVAM1XBQuk|1Iqn2<676W;t^IWHcfYjG=VD9SPaM{EO`XmUv zjUm;lyYf*8iWQ%>3`>6mmE!#fVz!D47la`JAyuPdStRg7bQOU{3?M0~0EbB)P_Eb& zM0%{>$tC`ma?N+>x6JDVA~Nzja~k(}I0!LB0U`qS6q0cMSM73Ce!^T<1j7tbB?wxLM`{T*qs1sL`hjX* z43Fe;B&^Ld@yM4~IamsJ!~mD)j=npXsba;Iy$D$1DrBG(6S7Lb7I+5z%3F{`v^1_DjhEtKhS3gAaIb9# z!9CnNfg!*hMS%xdf_SF;Fq7-tT!^B@B{24377NVE+|ss*5~~?hQv!LzpK3b)!6Zd7 z#UC8IqQ2@~y6V06V#!tR4QwzNQw#(W0t7-PP9b4ZCd|B<4B_QvNDo62 z<_!}jkkAGQ%@|{BW8>a!S(ep%x$3%-uB5B_zO~o?pZn|TT1eQuqhIIlv(MUVueRGd zyG**$>gI$=2J_AyeeW_AkfRwwj=1JN{pSyvm^BS4sk7v`zr8JX6X?-nSeYWjq?ldW zQwr0-=A#$fK4b9Mhqf)z=X~RY%dRU6E|oD?;OXAOVB4hXMa`3Ip2pCEK7aRd#m}Zy zxM;+Tn2seaok13QfRBwP|BFB()4#2M421x zvFX&s!=~mb&nX$75V+T74;%vz&%||e-g4u(i@nl^w12^#_I(H@1jmC2R3=19Er<6J zOA64Pgg3SAJW#~q!=|O8#;!VFWl~XtJyr>R4uMx&%u>hda&_J|N8^zu^`vRSDFTI{Kf!>Z7GeiQbN#TZoD5 zm>TOz6Fd{Y7$iAE>`3{X5187nA3gtlGjGZoQ5Mt_Rh@dUUKgOsC$c|!;(zigw4E2`4w=OL$meDQP%o3U#_D!k+pd3F@%ucvCrD>$*~6|s=5eRB34 zH-~$-{-j7WYq9@e!8DwtLOzSKhPj$X+v&ZXS2xduH5Z&xH@pzQr~n z(8fkD4X!CMkwxq^(*BJ#4}O2k(-yayIAa~EInDcy9yWcMKoo%1qlexyaj~Ts;Yuk3 zc%N+)66+X0xBUA{_O4GYB-zk5Ud=uGnsJ&jz?5gA__c@s7K7lePrYUQ#lJA)CTx;n zW5SS~Gg{G-^@WQ@rG3_9FQuaFw^(GDQCP^E`tX#bZ_SC{ug-7ep6JUq; zMkGbJKc$R;XX5%`Mm+?orr&q;kWW~)E$LN;J&g!Eh2eMH4rPl^BhwiZlSD@DvEZP$ z;_6qWv|OrzDDW?Mj<-R|NQr(`6iGsNS~rQMo^Z1tnkYHThiGkyB&x34)v{d;^O!SRR3~aNAPp```Q#U zyb&VBXH`urh_ztey?jyWFszCRQq%O|S(2L6$~!6-16x8um7>?IMK7_$iUC%^R5&{Y z*m{yA6*Cnkbk?JoRW(_qsZ5(x31>n9tVt`On54v75eT&&-lB?4#M|!O?c8+NrY98@ zGq@jM>J5uQILj^10PfPo}@9r1)A-oU*dP0=J;A2r7iH)M!fC5S1MB<8$FYyr;4Aigl9_X}r`-_&GRB46+ovrt^Z{haTwO);y8 zOtzENEGeYyssO4$GH+=e@oCM(cUf{0mA6bSRht;P#91M)0wsBcBckESdt&HBS-vgF z!<4dIw{Z;&ZrR*B>YJ|`1N=z*nkja?kB>OgdEI9@Uj%}cn zAtk<~id%&|Y2~x=SLNMhLsPYw2 z&n3`Gs~3=w3H~WgC_$p>6eahHs?4PlSb^-!yGZQj zy<$0KNQ^bv7I$m)J*gqfhG3nJ-<%_HD-F{?0G5Dt&78Os?LBJG*UQ|XvAf$mBj?5-{; z&sUB2imAp(9pI!&WKI!6Y6C!U+4!8oaTi~)+yH-CP^nIZy6Y#0KEtVZve#Ix=mn@)^3$Ntu5TUs^OTX1MBonL!)oSaPRMG~c=Qq5E2% zw;u)yDZmVRbDEO^Py+LZPX3)TDNdN@Gu4C0RINKrNNa}Fr>^+*;&2bM;Dpf65ib`> z`29I2JTBX_?t2>^Z~*?y3;FKC{q8@%K2{%Z7sO%AOo@jWKQ zATN#ti~1Cb{P>nQO%CQ#4l68RL?F{&fAFueax};7#<7duGWFUleii*ulb+=5Y_D(`DbU|O}rdX%GBA=390-14V+F@2U zVh9TcO@wt2Vb%pX4bAK}mT*lo=em7x`?44IZusOS9|T)NTX0F6Vl9z@3rY2IDD(LA zDdwMFzVplLeiA;(f}hIA_GxZCeyCKgVK*v%9yTt@Mm8$?lZ)zZ{_B zvR6t@4J2u1z9uy5L2xAa`e%vs-hRzKB_pYCEE|t$17rFQj!jc?zmQTxMQ1op>pX3g zfm%}^nR^y9kG^5p1tf|@aoC4t5>kOLW9xOun-{48Gfr)jf^f zc^dZ^d#u?uLmG5ZDxfi=xMa9fg zk}P(7|7N?kytID{A^67g=+2csmVE4jcVannZ$x;$;nSpczKJXNG!1nFHZ)}dNqq%y zW}vc5Jh(alYFii8=8hD(#HSAyLp?EmD`Os?M18Hwu9w8Ii}=nJ#0S0uRTR=!ykv?7 zQ_-DeZd(mxf~erEStjRR}e zxP5cOV=MP>1Ey3YwkpYKfv#9#qmi&&0>oY#mDAESJ}Ai^m+f8m(6$#iEjdxR)VU&p z_ZaFF*+xwi-zR}Wm_G?gqf7D%Kxo`Agv|kvtHnrDbsXaI%`@t zhcTShkUC}B<>PBp%o24GUnQ9i(i%n67_JDageWGoTntyFtAeQl^(cZ0DSFg|n)k5d z@IEjlHoj}Q#`Ya*-zc+w5)rL9Pc%=OmZ}K4`@Z&r;u)5hGqcNtUMb-PWvyDxa3g$% z&y4Bd7o9zNS&YZ;&$83hB3}(cdn<%dvlg>ROGqerm6BMpt7V;%=_H?&p(0vknt?N8a2mKfvMb?Npd1ny$;TJ@bV$}}vZBj; z+bPGN`q)`;KQ+Nw0fOO*>6(NJZ#D6q{wIJ>Zx+N%8Wg5eU8iMNP*?ctffxdr%8=cs z4m~MmP8jJkSSbqm#z-kPb<*>Jyb*0(TR}`?yl{|F7}5{PSMUquy#lTh3REn1318N3 zQF-kGuLg~AX-Qa*KJ9PGE4B)sV3kd{2;vg(SOz4e4J;VV5wpd*HZ$?7wzZkVd&gk_ z$zzgj#i|vGhBqa$E1Ntm|C(5=!k#iHdSa1#{hBste8i-j>XG@kP#HnQ@StR55|-gt zx=TpLCO3}mKTN}@6$&I>UIoP^L#HYdmCfi0+s7`EC%+}r?8H{Y2R;4=kqzu*s=RlS zOXeS`kXP=Fz&|zo+7z>tBDJBw|DdU`5o8sb3OlFWyh_r8?$VVInD1 z$E}c@8D?eyR5H~u@7Ddjldo~US(2B@JKYPrMFGKgFq{C%SKjMMYT^M`7_6~V7^;Ju z@wb$Rrr(qjRO-F>$fEAYyEhf6MqwZkci=9{{mg-!a_phy{tN0}r!a+mE)Pz?41b20WU%BZHd??Hx7D8Z15*Z$rkHF@5}RRL3Rh2f>cFwrj$af@5{t;tT?GJJPUb+29L$iB zjz?@5Sg?Q;PZQ+>@hLNa?1gHtZ!dKno$h0tHgDL}E5^(>coS(V;MTTX78hF}oc<`I zxMz2+G%7O!S$}Xl-y^CD?zk~TZGu^U!upDKQ=MJ5e>l5vtG5o1e|Xyq77IE$8C4Zi zs$01nJbLIWtADg)kJG4Qp(g`1EAmYfFMs2t%Qb5il8P9CjLbWikELQFHQnZ*30S0j z|CVQH!MuBGI>iw9>V2DZhAlJItE>p{%2hq?IkJDr?p50l?XfO)^?@x!#NQCgD}F`u z-L4!p*XdKRS#WJ*2nSZ7HpvK}I$;7U_O4&Me=8bewT(Y~DsJCcfHWX5P@rJj1M*wuFv}8Ci~8 zqa)(FVcbPIUyKIV?cZjij04)o^bbpLo(b<_i^;KZQo`{U_N;4mFi>fTyhRC5wS6B< ztqi8(U(`^P#2gm=~O!hFY&fz zt*O@Ma{R{Y|JWgBjTt493RUAPVewHhHZ}cl)06-8nJ*{+zC@4iJ?Qrryz{yV7gJk~ zOmI!FfAZ`Xf3W#!M5>aw0j+=ez4^C)V3y5JPBY>&vpBN`H9)`P;ZIv6A`7VAGv%7! zSa5r4q)L7!&5beal>x2UxA{+>|I*TZ8x?+PV(8sZo%|oy{`*__Uz+i!@W=PpnIH1(-gO*|^}43*4=#B3duO~J zBRLE%@!kINg|GbE`bTLkM0euY!cf*ec13scWxIdA_#>*birEb8Jhb;?kA7z3;XN2Z zfP5D=Pcl6v{5qu}vPt9Bqvw74s^4aWRphFD8~?=a25q}^K?y;pdft!;$gn|b&iGL; z|Jv*~y?^E#&7o@)OQ+nse0*&>jfompv=E9Y&!Mg8bfri{)_>)_`s41c&%d~54cJCi z73tyPJg(HJbHkiJX5qc2k6-)8Tc0;S6>_~wxY#spt=_l6p4Ep>9M_>jWaz3!bI_1a z;z?P;ih_#50O;x}rrBf>%2!t1+oP->XFwYc?YeWz)5^9kYiT5^l#OyI;XvCp<|<7F z8cAZ2Us`!jETSuGLs%h~>F&e(6dT5oSEuBSk9Cm3Y2mjhs742hl4fRFU5)H#IPVnz z{3!}pyvn!59?}LlOiG|+l9Ep_;ml5Q7uG;Nxqa!AJ65Q`R8jy!S*M$m*7M7&?#(Zg zjWpc3{*g@`n3VgIngCOR@h6Q$Ev!|)XVX(__iq85Nd(UE z`dNw@;$Tk_yUM1#E-%0ZXs4^5T)m}7r$Wv5iB`DCv*T8a>4c==5gt>8Y?Po2%EG*% z7@NiV344YsOV0K~KDEVZ(fQZ~ZK3acS+r5o29i3>$#tiD(!w~jg!BO|0F~nIBl|WU zXemmqjhoHk=JF>6TrQSM5Rs?gNW=3%bH5NrdE)r0XI;5 zI{prX1x*coC7IJ+*C}j37QtGY2HGkjt3Uw?(EL^LX9fz{0qzVFlR3E8t3=XA@_6Zr zPB`~+3NxefzM-upUf1CwO+k@wGg#+KZWY~C;56_|tz4Pk{QSNR`abcxLS9FD_P^&> z%tENeINaeaGzP(;?AolEc#(D*fpXO<*N{*CjDI4KMWWOk9jM|>{fg9CNa}&ivC};& zzwSM3c%yfa z1Yj5Fqisv}ZB)9@5V^z}g;;zY$xEkF7e&xg5xJys1m)rNX%;UAwtzi7$1Y<;k{frC zQVQNBU@U4`bi67Yi!9+93tdv4kn9yCn&TJAQi0-JuaNG{=!7oy6cq5Jgp&++)Wp3| z1-6z^tS&!lOTSTlV%b|7L&4-$qo+Uyd_+b1xOuemlr@@KtpZ;oDAT6=GYjz8bEk9( zb#_dSv7tK1WIvPGmWMnI4uj5GMjZh#>QKuLYjifI%=BlypI5Y z?jq7efDz!W6Bb`rmdBg+Ri)B_)U7wx4;p#|0V&cX(kmmJ_fLPl=>nM~Iqe{(LRAW6 zg*G#gkqR%6_rPEvM;Ll4ROtb`Y3#!5N6%BJ3Y{lDIOC?dLneSpE^3^X;w@Zd4Ip1t zq5%KPv);%!(2Rhgy$4)2VkR%5x+X0zlP3$p6}4hq`Iu&1O1oWyVoTj59xs`oBUyM3 zN|jL|s&AUm5D`JVV=c8z8pu<>L`h~g#g)fe%sGyZV0!jWHJNg4IkvP};1eORnzDL? zQ9&iXB#FBiOa9*N2(D6@Ht-h}RxS5JMv-$d#X^8=&2hVB;^naE^%R`s+%#suh^xk2 zAfZfI1@cT#DTW=mP5!cy=+;S>&lnP)c5);yaE@0^k>>~vjE1N{_FPq4+IE`pWJk1@ z_O7$_Ut{IKyvFoxw!0n3NL4lf-(;J#vPU8%Z)!h7`M$Gdm)lg`ncJ!GPTSj}AokT%DX z*yVTEJ^WpV>jd`b91@m~X}n1WiXeU4HShkWiHj>X8v~qOdyXE^HE%y|*T)m~NF3R3 zn9eF}WCFv+gWK)*THoq4d^~ntcT~;75i=^c1Ph>ATZrDb`Kc{!yXOv_^tuU`n*8ds zwR&{T{w-Rz@dJhvNMqJj*sg|LxE>8bbKkYCZ9BfV?$LwC58pWM!iz`EP5fDkaGA=I zyD5Bzj^XKzjhtggUb~M(l^@^M`YhYG?(yx*G`wULnkpN)zH8bIlLwEXuaH*xMzXbS zC-Tq+1`UjF`=Q;V`o*r}MWLZnQ>*@M?N3-XP_{sc~M^$BMUo_OQ< zi=8`JDJwk_Us?4dGe7(HGy#Y@$=K=oCqo4Un%hFu;4hdOYIeg|*d)64fQ!v|o>-bAQe)0PaV3L!HA71iL zKKq5|%PzUB!7-fE28?=S*GfG@n_!RXJ?K9yeD@nBU6Exe`L0M!B>C#$to(5;%-f2c`-<>dRQ+F7Sre~X$Yt?~V%w)J`l z>bg;L9@)97Ox}+Yr3~9Q*3na0oKS8S_0&P5zi{mz4CqsvvznxKx`zx)zdC8oV)pH| zKl#kE@3h(Nqg1TEe7tMYReyNldoA>=l7ruPu;o+Fed)>FYY-W-YI4N;%xCwmPZ*^g zvmc&u)340EwMr#`_^4AFR4g1UG&YNk2}+piu~up1jQ6h?5w+&IUx-$|SMJ^Tzh1tp zy_|N3TrtJk;=mylp?d0M*=5yNESO6j870bR5Nz=21GCbBP)y0kl~U(KpJeZzmKW!( zfA|;5`HmG;cBTENm+xG0V7t=AlKOOy6VGfnU;?;0#%A5NBK^YZ`+VS<(L6~;(V%ll zrO=BUD^w&&xO}*15J@ROEqqkW^oUYVd2dtz$d&sx{?n>^)u3fDuckn^Gqx@dcW@XO zwUzm=arkPSF^e6X>U!ndBp}t3+Qo=+;I0vVaLcn_Ui*NvUxxRLoijeS@<*49nsfcw z3lm;iNKo~+OTNCoZI>?rVg&x~#czE6hL6j)3_5~aEEiLW+ypX}gL1yG>YkoGdJl;j z@Km3Zy-1JYBA(Vjs-6W5?NpSZK39=o{~jhlhi_1X+{?CEJt<3TmXWf?EG?AJ+#v<& z^tXFfZBn zFW+hN6`hDi9gkCVK;(*qOo$!H0j`cDoz9Z`x@<~yuw?YSMLc76BNmg#bNCTba z{ZF}_UooRS8JcM8i1*$-`_hf<<5O6@hY(gpn5EF;MCN)00;o?~5nbpGPV&dq&f4Hb zJ=0v-uz`NkuAr{kzm;XnPK@lp6GjGN?_p~|Y)^Y|r(#Bk)g*w(u?um8{RN!}C{)m* zFt>XnaAO$QgIk_go^zExUQV3qfn@}AS5hRd&rB5ntoo>BP+m3O60LjGM$!9^)b@P$ z1&@s~WibxgTD5oMRioxNR@(tqwvmbQS*{JvGz|t-z_t078DHJg>^8UUwk^5S(qtju z6dJARI~->%u?8g8Vudd9Rtv-kC$^AKcFLvIC3C=jaYRgM5K;>S0&`(J+Uh`6kibsP zkeAusF-*>3wood8ZYh5JE{p`7|99P}4qMmg;W z*BL3VlFjOEmHLc8J)&4>+5-tlh%gP#pjZm1_yuhtg8Ee@6Cv#GHJFSa*MFGlBa}-% zsz9ApA8aT(Ad9$CVnuq9qLIN)kAc00KPu=dyAu8X$L;)Dv*g6etDDAO^sSALw;i`y z)*0bP+w4K#)ZIw*L|KkX5;n?o79$R_ZRuUkzkB0^OYMTBX`%zl;E*jGr(~m>;i8-J zx8ue$aqGk@)-V5_{nflBcLSKV-iK{bcC<$UWA&3S1293~c-jo!C=)N!$sX|KL|dM3xfp9~T^nw6DO3}jITnHuEm%XlZH zr?NOOQwf_n>13w-o{6adDMCozQwWXs0-=D05*=D?pVm#Ao}g%H9i@50_zQE2Spwvp z+&NdG@YK6h(nfg>TN1!_ICVr;S||X~v}V>Gf8N)57PCV4(7uB|Jp0Y`x8mToIGo1J z_kKgUv-*pCI|)fwkcQ9@4YQA!mpog+c_&cjVYvMG}8x;v7sNIfi9Q+Nn`R( zVZ9(_U_g)FiU%DSRLI%^)*360#5%AUI<>|2tic$@_H{#g5Bl@Ve)Y4<@6=EuN!Q;F zs{G8jNV4fz;YZ$BD~?aamYr9Rob#5+SHsD(w<)}QCryn{U(4CFThN_W@S@KX2Jw+N zO`^xsW!?;@#fQq6p4j<&HGPT=GvX7{$F7-kEGO&ka4fx0pIDGuDyd^WQaO~+N!Dq6 z%Fm?!!|~PJcQCRMjMO1L`*QY}#wAG+OOVCE*C*B~^`pPhgGgdgP;J7+{UcN3d0xky zOk34-QvF=7(BHXdkoHlN(do&235mm5VsTff%C+~%ekYIIx#@BBrFp0ynR6@0W1TUz z4MF$#%nM(CaK}Snw~c6%-+D~w)DF0ZkF~2!U`_+_ z)@P5et+~(9er)3UF&FsKWsWT5_{EV5NP+*-${*TMw7u-5$Mp1$-ZlBE-(GNgCy#6O zRUk9Pua5NB*4%&hrpFH+JG$b)R!!VRL#Mvny4esn$S+3ESTRe@9vK;fyJ6ggzqjz+ zR?TQv3aZ$h4jH~Hbi}kD?AMF!=66L6m%&euKYsFmIX&kVi6r4nwR0L^hHiQ9oZlNo(R9jN zCSLZwnKzp}m0IY){&NeRUu%X8{Log^WYJcKp8O{-YGBHQ<#;mze#I}XzW0Bxx~G4y z{_6PeZhlI~^1odCK`o&{i&_~5rf!bujwAc^QjB*4H&^x0$(@*mQ$}zytokc)QBh^# z^iT*m+tk}k=!2%NQ9AU+sKSlt7{rOFS!=x`XlY`{(ftAj`%mv(xBB^Q3x~}d+-Cqo zuLw{_2EVn+o)8#K4}*}p5D3RQ&Ys^``@rA5^c_1`^y<;)YwI6rJ$CrNUi<+c3v{e}3HZqT**i(>x}agC}JYAjKN_d*I1O zEv=S(eE(s`ii$<9KfL?%tM1_-y?y$P7_4fIg#S6+&(_5{GfP5oiO0G6PnXYK&yC8( zhOHMDh%#nV^_Ba#8eaDAiJ$<@(ddG6y$;hv8 z9TP8t-@=G{kwBoTgrJOBG~kTC*qJy?_BbKL{-L)1jvA#{PL0;aaF}q2rr`>qm#dz8 z&nV=lPW)us^ZGwz4qjhTgIU~wK|7A*p~Yb9A>Oj%8u8*iYP9fs)QCqg&gE9IBOpC8 zs+d%kNHLI5R-h_%Wr&eH>%T;mVo~pack0q(EiXER7Sjfad_sGV9x(S30aF^LEJ>g#ljRk;fw1`SnAnpVi74BzBv z3l?H=6g}igZG)tLUcvKj%{mc6`xzsEmF$$`s*in3vVCBPr@}*^xy#BDd`WehEqMr4 z7i@Jrrx{uS!@Kaj;cbsYL`4VDp}muhP^5r=hAn)RNc!6i9NYaz&M$^F)`- zlGA`adeT8}C;GUHCb@3E0>6`tD5P&+$~vVft;uThn!VlmJa5TkkN*S+WK$6W-Hoa=O+(wG|yJ^tK^qh#0bO2)Uvoz8_fEL$4(ueIcT&(73vCa zq`e|r9RifwnDY3+FlX45U!U`qd$v3y5`#C6UN~pSq|7dfPX<}J$UR45e;y0f)%fq6 zapR8m{VVow$w>V-HHd?(&=8!L39q_OGX{=f9C8oUIJNlHNlO^((@mo{zUxRUtJR(3 z`o|Ms-cdzSC0LA=pYSAsD54Yl56|+GB6p^#BGlJaA$g6}vn8tg9d-Y{1d^4E!#fX;` zFkC5WVF5~vDnGQ}W=gF!-8I3UZdCPb&-ORU<=Nh!!#iBbo?r2iZj?*n8x_gn=X9Jn3=^-AM{wvPz}?WXp5^w(cRdd&n#D3d?=} z%r{t?Ub-lxVXWW#Z(jU{DaByw1f05T_^c1jyRDK{2*0Um>%kq4em2}vxzZ70B(QE8 zT5tU~QfiNuq&!E}5DxKvJ)9G$9~$Ea+dsa2%GHwxjgeN2iP5}doJNv2syxZy4*m9q zN0#nc=W)TXsc)ZrHBSIa41TP&l zV#-MGklmO{Jeg2Ijhg~z3(;Sjb8Bcp7ohjR(PecB=jvS>AAhmXdCk}bn%pcQmYkkA zb$nFWL?G3XJZ6q*(`E$OH^KLno@L^q)8g;m^u+4ctv-ZYHgfhGCS0Z(0&g=r2;TM z7E|x!uUj=|&=@;^5S@Q^*+=YYK}7cb zh8d4acxIHkOcVV4io5>D^1E^d)_0>e+5ejh-ob|S%EHT1t|xaaziZWV)`q~QX|)ge z(BA#m9Nek*h!N$Vb9F+$VcM>>Z9B?(r8xQiiV-tSpmRvPg*2lb8q|b+_$JB zv~0k_5=s?QGlRN4ggOf2K0M-Am{9-WrEh(2(^I&ESrtQ!H;j)>AM76Mmzl17w#A-& zJSABzNc+3<-#P1afAxm_Enh9k;lZG(6udY(^QuMNTekW@%Mz=w-#P6DR>Tyo>j14;XD0GFDrS>M4M?^g+&*sLXi`%S zO4_C;cdppbwo@0>u*zOH&+cCH#E#{P8JMbF(uA^ajx3oXAXFaTsoIA$6-Rtd4(id< zwsS{L7_CKp&pN~C{Vi8TzeOt#ZC^HJ;3)QoIH>eJD4PUw*dUcERw9$mV&;1}9nUM$ zuyRyW2J`ejW1iT#VtMPP+&U)MDNT1{8Ixm5=HE6vW}iIC!BF$JHax1B!6TJN0fu6< ziMxLB)jmeBN*6L%Cx;s>QUZ(F+eHXOAtt3~lqF#?R^}e7#S}TzNS@`h*U6Z8fRUoe zAOe1!vD9zSXvh~Pd-%JXp2+RWm1?r(e^<SZTe5V1E8p5}a*Jz8!;u+GXh}q$VJAx96 z26CXC%-U=Rr?LKc+mg3Wxke*jSczs33vgF3g*js$7L59$a`l0)XLZL>84cs7F>x`Sh)6pqZwsPg%|u8XjlcR+m=0k0 zjl3&_iM({y!~XnaW`>7f!pN?UJ^#i)#Vd9YGeSyXU~N$yM8D4$%z;_P2pSBf+EA&= zE(6*M_~j+Ta*t44wa8)!H3A~H$ggDX7B*7obUzx+PL!@Nw@_UODy<~Z#w!=A@;^Ld zCDSG+uRvPkf)xT`H;So-^XU9WfAxKpXu?5UEa2MG%UUjsAzXH==fFzBI3RDD|?kHdZLsF5i zP(hX470yaW5fbkx)J2sB0?}iNbcOxMC$xY($>B6s2U*|aEMPn$03JLVQi73u>*2jW z+lfuDwwR#?#nXn2*MQihiH?18GNhh3XtV`?ULn*yWl9(X7iH2wDtZM?7mk>z?onni z92IbBI&`iGMg39#85D=#%w6keU5rVkGloo3uoJloRTi^`Ot2-R_FbgPNsBafz$o$F z$}Xijt9ha}$8;WJeUVPtv(H@iNj!2o=Lcv#dwp?z3A~sw+_zg#E4u(h(F*!w@_~KD z#`GSnuSMow3DsG}3DJK1NGysg4Q!N#GN!6aGH4(Qn4^v;KLPd% z2^G|0%Gbrz?yaCTPt1&aOaVIvzsTy_jjrbxEj~;O*+fH9O$l<4w(c1VBxvL zru1|H5Xms3Kb@n;$jRjv~@AQ(;CY0E2BpgFJkdp$J&d`|9zDPkiFM6E!5j z1JmTbH&<Ww(0KBm0|7cuXpO-ky5Q zP2D*Od~?&po6``#Uj5BjQyIki|L)!Uckg}m==mR9`)9q;Im?m*h+lD|b2sZW zVn?rHUh||6%)HqOXgOug4TbN7kuk^ax7}G2qi>y_^z98%DngM5oR+necpjkM4;)wDeADZKAb=wp4QVbMD z{Yf$6)oFUae2M~3k!?C}wW!kvjoWi%pMCT7U2mOu z+52bSY}QNBf;z}@0jrh{bKLQeVYV2p`j-8Nskr;Wi5CtYW9hb|ZIm^l&%if~zvLID zzs}-%+9V=rL8>hu-1-87%^ks-VY%rYvxiJ5TM2|f07J^LWaTy6Ko!)5#~zM-!8m0} z^43Y0o8DE93W{EI6l33hP8@q_&-&J*2kZj?`EY9+yZ12tor4XXgG1 zatD0eSq%HF^^amQb5t8q_V3Prhbl)LEzTG+o==}aQ$`XGIFU>8((W~mE#@_zTHL{# z4zxVH{iQ9ADmQu_yJ+T+iBj!2wA=Qb`Vw}x%vp0k+4{U4GZk7@+RYO#Q)@8O7k97G z%<7Rl0a->ZZ9DJY@(jlSuf`2yE|^|6x7l)VyZuRZ^hvQ)|1pn@`aM#KV@>Ye^6dJ9 zJCrUpG(pq(ZIiB$ul|WK1LV`nMj&fjH*@XmIMPaD-QV=n>qdrHBXr zrPcSXJJ4bf8?9ei5ziNA%|S8oQ!2Ij!-d1c{Jo8joARrjxqSG{3rEdH4+-0!l#wqO zHihF<*7t9I#-wKxh_!p_BL%|;;qxMts`PcQwqM|Un)oSdP&WcS)XzT|@% zlX=6Y&8t&ti_d>tepgmPB&Xw{hP`xje5tIiDAlEmWoeWJcv+C0)e{vM3;5#7d;ZV* zhlrA)tM+6!cj)9%{fGMjW6+inUT-DmL5!+YL0>lU@|MI*yvT=45a ze&X4Gd1}{6{RdilZr7?$T=IdTeTMK2rh70UJKcRBvt8t-!@D)hRLe3(^d6uuWSith zNIPo${Y&5Z(bnfwq3RKCgV&8&uw?H>tHKFZcjf*q&wlE%Uu7$NwpWc^m}yhfDc+1B z4Ue1+73Ja;-7l?sAdc*a`Fq`U>@ONI^UY-uO(P9whQGG%C+pjGYWzuw@!7_B@u)dh zmR*c0U>*2RFa75CHa^iFGfq!jJZ#z@EqX8RDhY#Rpbu_+&XyKCjvmmkljNiUBgXb? zcCwKMlgueDIxO9~wH`gf0hpE1!`qg8^0E)}VA%=BFYxHFH8uUy%Dca^=Ev4v(Ku$c zQPB=Y;i_FiBaaMvY*RR^#Y?5S{L@Q6JhbnidBdmHp}P2s&MadoMi8pqeaG4eVfgWO zy+_4zbK5TS;1hEfC|)`0)fTflO9 z+$RqH11 zM_)6!+Q2-&cl`^y*C=L)$>borckAif*N!6xth|8S*zb$0?|bL8*Y)b%liWk)rQ`9? zw&$PNwaRpU6q5K0d)M8+`RQMnd9&t1Ohri*fM0*rba)u3N6RKg4@R-!^#Z1ohG3K! zVgGo`bI_fFBmZ+Mnqxd;n=h{(RVjIa`5EQas7r7ozkv*qJY`0Ef>*H z#(+3E%`DkCDqg-6{ldQWPwiY0-(!jvXi5dN=TPf|ElbsN&L0jHmX9b0jvY}}rK&Df zWX@oQ%NY2@eH$KcdGXe%*SwOlfKhT|#od9b?8Qbe?3GtjAO&6loMYhC7Bkso#uVmP zdWjubS2SgzSaq<4lr67NLsNhbo4wjWQyB9|VAe@yI#*Hf!og<%;5MqZhn zyT)+M{%rz1nxf!UQmq2=s!1Ry3R#5>1_3>N0goO*47ZMhAqu@a-wC7g4rztBI$cR& zX4B(F!QP|fs(w~x&%@QmSW_?PS{hFQfK+L zA9(wS#i&99>y$l~JJr5;PqYGIWW_Qx>7!!!-j}&>##o=ieKMsuV6&zRb@>&67EnKl`c=siH5B+oW1VwyT|)Tll&EvqmQf6wuHwZ$x?Q|uf6 z(aEW28lCH{8tcfeXuzX{%!2weJK7-7OzUmYWfQ+8-`7*SS2Lz*14jP-1;3CxY&K>A zzc0VX)gIv#;}XD2v{z@j0LbedQ?6OIcm315R%4uh;ma0 zVER%8qyNTy@yNtc8-X&`wXE9*al$0qww`@_Xi*nLiF9>uQr~e4r-MqXoY?d>rBzwm zWLh;Mt)GuK#6_M`l7PJC4jva}yF7vylT(DNiNY0aje%;cTaOF`w@X1MEZxn-{4s}+D#6Zh0?q2O2QLu|g&6_@CLKQE@w=(7A<4^q07j~~! zv~bSE$>OTfbFBaOhziTGt{Jmnl(VW%o#Y*9IlPyDY0`j^x!I#rOCH;?RR36Y?#@aK z74!jgejE#Q*{FG;>|&;}qf6HCrB(OZU5t;LMS?VVy>!G3tCB4pq6LXr#^E+2M)(Fs? z=E)b@3!o6`v7%FkI$C#ac*Hgk=1;$F{3U8J<3K(eZ7F}ZuZxc7J9_-sGdo^>Y2OAa zV5u>2B%14R7u&Y+%25k)vXcEzxsLTYeW*01Wu|tWu*hvs`+n+k*&pH2?aNaj$RJG3 z@68h~)ox@JhAAGM=Xb9<7~84>Dbr zxy#3<4;ky*fSyXRj>ylKx)=7W)k7)Wim-Jn)^DGFy>9~)QHm9?rXO#9X4~O7T_7YA zef93<{!ffKL$wA_q?)LiGrTl(I<%LKoI7FA=+tH8maZzO&)+-(UD{OJ6ZYMiosAC}!5ie3r0O)!2pu zEz4S;(X0^)5#P1>sZU<|K?jj78Zjg0ewIrPPwja5uV4J8!()M|FD?Evsp`4C>kRIJ zu%!1)zu{MA-4ewqBvTUss#K8njY$LY5xpJG7!>_El-%tNp zrWlzucnn=I&C*dn`ETnV{|}4abM=@76yaA+14r_jrsPSIjxHQNf7Ho`RY9AxWe|#_GPONY|lpuGMZ{VdhotgOS177 zPv<62=a`?eA)m4NnUBnQ^QEKaHue$dg#nKpFx;;~o^sB675P&Guez9(GPd*3o;x=@ zw)(&}{R(5*rTaFSt#3wiI2&qJNEoE%-fUEZ%H&O(V`ph&T)rcMBfjVNu2mJiZ}u&; zj!DdDD|D#7vG&1L2e$EH@EQ|@WrEN-KPd+?PK&#D^RqXNy(lUq##*W|*(v`f-E}{% z-_L@3=v#{vaEIJgi7X0Mz05F?ssI$IxIw$~$bNbij%uZBuvNW1GmvJNcUBnK%azD0 zC1t+4g*$x=FHJ5v_*kd=nvEn#0tCiH{_dr3n`W-ez_j*2i^nKtMRXOyr+2QnYs=Hk z#t)}ra>Jb)A79Ws>5Y@FP(oBjiibvCFX)GxpWNQwYBw8>GaevIA~X?)&OkQ^Df``w~*kBP}nrpYjzu%%*5Ij)NnRiaX!gVvmieyhJK{C+Sx}F*EHD zm{QHbm>8m3Ebdm^p%#p<&&pvbR6LVIbsD?-ssW*f<$N6TZt|TknOkdju znlT!+UtF?As$qGdA&BH7)&0?lAkq+cnFK3eIf9Xwl#lFu*&alSnTQl--sMYu&?fdu zeI={&xP{%knk%_e@mRj8?JjgQamvx96%7S*jsMIAd-Y#vG?)&f54Dh;-plH8epKKo zjty^hI9If8vEwgV^%hEU_8v|=VPLxKHjS~5Kj2E-nH^1laaYj_l*q_2X-Z9a1Q6L3 zBg=&D)mve*c7}uc7?FJ3?lC$)>s2L>+)qbdy-EZgSw{KAq{MPqM7RXvVf z?^&(W9srRreuCODjI&yhDSVN_nKpPV{oayMO{bBpTm@bh;o6ae_1E9j{>mZ<|pJqUcQzbKde(OZxx|m2&$>cK685ENG$9HlOn+v zVFlr2AAYoQRh-ZbhmSa-$8)CjHq1A^=SD})u1q7#%p)>V0hb&hivB>6ZxkWGAoG=C zBTyNr0EDif=L`u#qF&e9FfzFVVC8dbM;t{GSE6!v1#&c)2$UNnx)&FjSJJv?68B8Z z+0L-nHbPR2BWf-m12Uru5;nhr zq#&wuU1*5Sw9R8Q9W;-v3h9*#lG#Hi8emJ9)aKU!FH?Q)QCAhc0BHCHwfV?*ihJbM zziV{}Tqy9kf~W|mlxi^rbBU>760!ysJl2zB*b9jgr%Y>j!~|qKW|0P2nBMSml*iyAjP zT}-VIQ%E{_Oj>5=%db~iV8YgC{JG4GE*G22YZT zuMS>{sPP_#RKEgYw{Dk@oHu{)cu1hKOdHzUrd}0B1sRZeqX*}D0O?Juc@*&L~DIM_mwDQ?L~+>)yQ>yi%&WXa3` z9qX~Yv}YZ+kE%$ut$WFJCJD#MB_rpU@a9W^)?>xq4Tfsq_3|aL)|jU_TS&G-#Mh0v zV4^Dj__2Y#`&~Y2o)$5)sB-MYbQN#a{j67YEV^RUJRjV!-+rR~sqM?le34iH`cTUfgR4p` z#Qv*uZk<1DT4U~rx0B)HJC>OWXbRh+;nQ>dfh@dI$d%hiwk`Sm^6wkJ6;DP~Mz$dv z*|(YG8K1j}i;G6ijMNN?xS{F!Gr)0smv94`bOzH_&$1%$vxDB@-jy1^Y5`D$rn0wo`;}*?s zo@in_Tg1GE<X31==u(=g zwtQ>v;amD&eq`*0nO(lBQstwwk^XkcHyp;xwvcM)43b%XV5?2bbfyOO?EPEw-gfoa zg$%B$$dRF>DGb+-yU->x@olGce!ji-!EbJO)Q4%5{* zofsWEV8lD7T+55tr%ag2Vq60#k~bantLuIuoa$4du=u~c@;Bk}HgYR7q4~P-B{{BBdKFbbqQZ?5dt_}TF?AC2F?@VzFTu}>c}XeWT{z4~G=6~5OX@M?=$k`SJ^iKI$A$4|wuB(=g0&@(+2J0IgCPO8k@|K{2Uerv()zV~OUD(ehn z)_G52>Q)jKlS$%j8B3U{{MA+Wy|8bC>Q-{69CF(zA*LE>QN?U%JN(r(_fH!%X6(RG zXin3Fgb)&W77T^(_^D%GTmR7VeVfAqO7Bti%;{f>S)>Ew6)|?uP&W}7At_N+$djGw zZrFUJ^x2q~BGELcn-6rz&?88gq(?XdopRArNHB#*KM;>-QaLD2G458O)bUg~HU=uH zQn2#CkxI}mCJ?e5V?6ziv0B%Y$3${V!mo=sd*E1iUse<(2t#i1K|9plcqvYdN{m#> zFkSobBbA0Lvg+1Uy2tT72EUL9bYid(+iMbjZHifnIVT5UT7U#`OB{Y;IQs8vS@LU# z_bFy+VeUFG{1$|0Xjj$lbXGBzYH-iMnF0*~rMRupJh($zT^-66ZwgO(N8E{$#PzZO zqe_mb64TVPk59Bl5sF!rX{SJD-HCuKV>pXwUsEOG?oSmrw7q)2mF?m)Xec zH?BLd-7Ig#EO8$-N*nHlFjkhFxYuXU+6yqFiCSysM_{_AC&LVcMpkOT~M5QRY_cT=^@I+Aw^X>BL zOjXG&6jU51=IfMjxX}@lMumjXW_-P!d62bS`Tk$+8eGN z;E)(PQ*|cZR}u5G6thm^mOG&%Kd<`VjPn#4U_I8x>5vo{9El9T(zx~DmGdA0iTK)< zcq&_|0vUhCUAh?48)-yA>L{f_K)E8L_+P&#y=c>o7l0Z|6@`&Y1DlOu@Qrjv6J$s6fny4BH3UrAQICNcXak;z>FTPJ7rePJ z7>Np3ol@5_sQpRs036wO5S!_QduXpX_g!HtI3exyzU#+2F(vx~f*O(M!bsN`8)7?? z*zl^0pj=M|P$8V+7g8PO53zoltZ2Ksb>p70;MX)(;K?wwqHX1 zx;IX`3=HIIAPMv8M9S%rfiEhj@)b3RUFBSTu@MjGgJ60BsKbrTq<4!P8U@5CS+2uMUL6)IyY0SFhl^&i$=_x zI$#9#3F|~4>AiWh^vVJZY$zk;NYRk0bp;w*Pa1(d(SZ*DB=VrCuEcuor^%|M3K#-B6S7Kj?t$}e%`)TAUsLQ5 zsF!bL6z5*Q?mcD?9+MekNw0BC-ytJ=JLQ!xwf*Ypue*KPb+HJ%&R!rm728*Q=BnTR z^2#4Mv69d57iYd+1qn%ZIUGfslc)5dNia>pE2YsY!|?-0WLHP8Y}et|gY9h#hK%QO zNcjSebG__?;2ef9IJ?!b_V{$($JnqGcBoFAFs8m;75Njw;bs~A}c6{5;b zANYMUZ-U>FL>V%>;eBHX8Bw@X@Gnli?j6&vx9E(TONy{mNb+8ryi#6>`O7Qrh@*g8 zH$`?qcE2eDM@T4ZAUM&RGS_awFtt@+17UJS zg_bddPbNDK?|~$Cl00!@&XBROPPw>wLS?bXS?_5MvXYt$TOlm#Vh7v!ta~@RCoCR0 z$N9;*qh4c<+}fYI^h0-VdUErjo#rIT*!j#hr45=(jm&-q_3p=!YjP$riqsAp`WpC^ zV@;2my_FNVkeZw({dJzs`|tS`)=FeccCGsKi{Erit6`SWsto;3AfM@Uw9h9N6}EOTMw7eFlAE>?l!k4^yj?wE6{ zZ8r@c6x33whso_cvgacY{VlIxDgRL*1PFPv#xn+4Au0WW8H2_=vuB+llT0=2w&Jre zd7Djz%REx5Q37Lehdmd{PQ$7j{wl{c{n3TLXo@!avw}<7&T_BBg%QOyOKiF*Rlfhv zvtN9%b+ff$SC5+e8}r`g#F<0|I1{!VJ@l2;_kL&76Ncp|w=D-wTOCGOI(tl?-{^xg zZu-#dTa+SHp}Z3@o>i~p3E|%^`Re`KmKq|?88pt;#W_9I$B9hn+tT;eJ@Vg|f6o+Q zFhqw86<>ugEcVoKhe-KKwDQ0u?{JIR zjr8xAe(RD*N)9F7>csZl+9b~SH4c_v<&Rgr&llE@;yh%bap%&O@F2Z0b$bY zu52@i3mAIxA(z^{llBnFeD7ZW#J{Y2!1qw$7mpsY!2XLjemq^$Ns_d>!Jm5W%Nxsj z!PcWEzqtB-z`s1}O{$y5Wgx-Q=~ptIcfe|d=XS1eI8)A7JlxdH`9oHA>5ql)q~0o+ z{7I^;nVjK6XU?m%tBR&TjJKkFWHTM-*va^k5iz}Dbq$zsr4$Jei;pXej1c%52t{Ka z<@gLcKAq~$PvlTVVZkpS^;|yj)aRX6B|8><*XE~v8UMoze^I{J!F7V&yY0FE{_^*R z^%;yKrhn4siBc6N0Edq@7EZHRqp5p^D}leX;_f>)J%}HDl=do-SJegHth}`ccgTyB zA@@_TGob2HuVh&A;yVhM5XMVD!! z0ba9g%LX#R8B_sP&Ieq!e@p2T#tcJSraiT5t@w)Him6V4WZWHaRIN=-`hGi(?9&tk zFWr0i0;!#32VPZavtpL2c6k@`hRDA@-K0K4FJh|5y7WRsHF*X{5LasIP*~tRj|**x zsVEeXnA{%TxkBS9JHlc8&+S>OJ)y(|kVFS()xJ$S&nnPHg-TxMF8+c~tuOAEtDa$s4#%eq@dzLpt>XxuCNsh zornw%N+Upo3+0_7KN`C^IRts^wQms#UK^-dPcJyhKS7Q{9z1Gr4@YD?n))arc<_j>P8>I*(%3 zCANyb$iDvT60%byT8oDA9>D~dHh6;JkQ#`gyAz_zoi)T`>B>j#6fqr-1uPH*4JnIy z0gFm1YR%}xFBmq>JO({0X<<-bEEqo3@(KwHF>a;g6jH#)mEkT7*P9y6$#`;5#}j|0 z&c}kIi(BcmG|e44N%u*=1w5_|R5%i{$J>D|^9q9Esu5M^w~F+lK~^E6I&ftiA-W=1 zbp>?*06+jqL_t)&Ocec0`%+r`3TM_ST@ZTCQCcuN^6T=+*xi76Ve@27h0O3$8q!)W zH6Cib)H4X;g1n$Hlo9Ia5W?x9#P+rci_HfpIfgwj9wwCNfD1r^uY$1>La6f$i>lKQ ze`{o=K+=RV^JFAwJfG`lEM`b&BKXXEDyVuCz~9*kNf9Kqq!WGg`kqanyzE0444G&` zi7J-b@@`nqj}pIFkP_38)xkPi0Nl$FCmr-4K>wQ@i9%P~4|0Mwp8mc0w_iJY9t^sY z@0om!9X87#J0|s_A-igXTjQ<>I19s>QY~zjOiSlE87@cyRii#$Nh=CJ$V*1e{hfJl zbvlGcQx;ITXxI$drC2J2g{1hd8u^wx_Ue(fPw*%wHzF#s3h5D4CW%0(%qU9ND9$?d zqo#LEy5il_u7^){sgyH0J;xaISbg&+mwxEtp;L6Zxnyn{yXfD|yG?SrV}v4v9oy|* zmtIg6SK-Cqq!yj%F=0);BNe^)Re|ytQ|Srz{j+bmdEABaqElwWcwm6PC^URXi3Gwr zX0Iccx|HJVPomJevRU!vZH+3q2f<~Zi!>+iQ?ugF{fac_2+d4Y7dq39q4?8hzF?oD zlveZzrX0cYGs5HahF*nxppc1%E}*YXxq+(>Z^;nuodu2d)7vI z?$&KkpZ=wO3Ctdiv+d1hO)JfbA>TcR_kU~MLoe)I!%ajzi9v%Ez5g-^Kd@s?-)aoKmYgsBNa zV7t8eWl}}3f5Vsy-!}dFDoJCeRX8P(_bO6Aj7f?A{POpg@81*@ooX`CdDFq-7OKM` z%#?GpB{M=JhEuydykqKh9M%{yLNf}os{N@QD_DP)BE7XK14rLBB|%W@$y_ znUvIXJJ-KmVqozPwY+fW`bSBLxabJj#zQ;R0+DrmYY8Ky>8ft_9D}83h4PB8thN;} z6Wy9u8nIu?<)h}_KK%x)B}Dsi(>TNH2Ir$KOMkfO37fZrWRrYsWReOcPvMzECj7^X zeu+PmR}*Hw766i_bTV;FGv_=a@R@R{$Pexuo^2@rZY=j%K?jRj{= zVA=o513L~yJ)vBMvS$w(gPG+vsf{_Zu}j%>=Xn?J{43FdRzkO6{b33-lI4&pNO)5&A2xkkdu!RYAiN#;ve5A(b8kzh zzfKKaX!eDjEC1lB&(Wsb4K+0H3!5kT{8PSaL_6T<94jFP_8QQ;d$fVRd{D9PjhJ0= zphe*q;Ag&|d4j3iFSTwleH6eWJ6CQyyys&J-ep-@3hms5b6VAYj>+&G98|wle0;ts zk)_846$3pBLT?$$_trmR!ZE8V*rFeJ@1|#@l7$}~-uzvQBNvr38|O!gnRIu%#5E zx5$vNNF@kX=ML>X@S&EatM_jWgr`^h1@dgSpQV^3z8ZBE@`mSzVD-9lAYrU2(p9U= zCz=-v?-MixUs$aIol!JC*M!m$mG~=42%3diACQfaO;*LBmJE%tiw3H_81!C#~V^}V+L#Gr-;Vq z*UUS~Gbzlts3TR)gOYv}i_MPn;EnD-+&QtbR>C{eU4Mox*-Rdhhw>}N%rn#9woNsX zLd?la#b8bBbqbT^$OuBN6zD?(aZ2^z5q$<(g#c2;ZX*uzLkFQ1qIgK_W=DP|`@RRorgtM0Z5i%6sV zl^HkLeZcyZEV01!=405v6pJrQyfHv+Mp*H>fNe&i@7_4W0Ss6K(wG0zHT8nna< z1M2m^yfU@V-7~K7Yb`TWglW{CGuJK{I`yOT-u}6jKcFvLN8L8@@^?(W8oaJ7s!*E* zCjk{1kwe4PiAc@{f|YCIz2Zf>gcpF&!0GklFMV*^i+gMfaPmZ~{<1cxTX&~SgfFCg zs_9p@7~u>_USKXp6?X&9(#a2k%@>i@kUK}wkXY6!vj$2dNL<8{@j*b@lrB>hf}>%D zr=*Is{!8Ml+1saH=X{?X?fcmbBbShx2KVmovxL0V7q?Bm+QEG#N#{%pwpYBJr>C)) z=5xDN{=~t+^8ksnLAf(ze@Hsy3{g zGi*w+)qrhOEnrh6?6tb(;4VVfP?+~wmf1&%LO|=WHoMryC48z> z9rNFz(jwN=&Fkc|JD2Y|9Q{@J@7?lDe1ESQbQB)=FCIQiDpqc+eEs+f^K7vV`?suW z-J-%1Pa4d~=876;`zT&AYK}G#JumNF|M>Q0s&hFyG7Ej=1CdLMZ}>{}i0$!{{#}=jM|I80eVd-$xx&1##iQnuyev{9iTuoazBR?nW(rGo`FtNN59>3~y1111 z^daLH4WBWooPge_JM~=_o@chdY*Q^x9p_Nngv*(IUS&p*FWa}?IZp=X!Xo`w5+EGW z$5}RU^dXPp!!1j99p20OGZmW63I4My?nnWKhD&YrA0PW{HUI@I%%G)xze%v#G4=qA z+t7Ne-(C1_nA2uNst46gXnUe%sb-(q#6&g~S+D*+%JG6Y^3ti(NnSFTWSq8;*1)lR25y)kwS^4;N*$X1BU0W zy24`el~gG;fk#`GeDtw@w3~=`cy>0L_5aUodR&JS44Hat?loXZ>qZ15kqWTAnW!iI zSJ3jcynovD_Kq!7A+v^`?PBYaQ5_qG{_E=dUTTfmK!9M7_S%uNzqsbda;JW}`PPO< z{`$&0hV^lJTpRxXsk6;?APfcTc|hqZhn0 zH?)Kw9`rLHC6-~`IH9&@=-&3$&#t(OI~y?pQ>dCgaOCqAF+}Ygt(jT;7c@`$r`0xP z>CL1Lue|%_v5Wrv@;g}8(7r>iE!_kXR*!sf#od4R(zh78`L)fx`u^#qAG&JH!YB{* z+N~2iNRlJ((eFI+X(vJ%+JUsg%GD!gKe5~HsA0aeFlE5-Pha`l6XU>uj@~||NEq@< zPCq@XQx=#{UGT@pre*|2F3>{v$TVZYs)EEsn}0mxvhTms4%I#o~C*JYlssyi0`Ki2L8 z(9@$j4E^2Sd+)ud_lg7(AdnCS0|pyoV_af8ajNZSzt}H%A$Ibd*u;tB7RTMVh$cXQ zF(3iz0@YPpN!xqhy?gg=FYkBG`TxKB-zr_=Z~yz<`DV_XIdkUBnVB<pG&$-uP39F>d(4p=|e7rjs68M;((WN6qx%0=(xNO*Y9Dxp*p*G9Z&A=IlK596k7_ zEB~G%(e05$9HyDe|4jHu$kIwbItc-KO-Vpf6?56Ka~Yk8^b=7kbQ=PSyOoyGDp3%s zZU{vNwHmpLU(EIrVwcU4dui!@Y(BL2E9)LpFz&@moH4qf4&#@@InpfYeTVmdZPQcT z$Bwuc59NA&L0(WY4CQ{t17F-dl-iihP`@;+%N53^T3v8#tj>5{k~n8yN@1pzJnmy zNixpyQk1y#wT(~gIMU-d158lU(63>MBFMbxvF|y0=$=&%h_6moMj8%dDFRO8Rek2P zP)3Pk7nE#e5Lz^A^yCOLt6a2QdM+bU_HZNf9uppCJW{XXQ-WaBE~xM%85sN*s&q0| z#71O8XN%`;+L{7IInZ;;=NYM=^Rs`gS%X4O^2eiu16!lX4*o_!TT3(%(!sm()9D?a zp?M;!g{~Y8j2zY>R%(c36nQ*tD+L0mned1nb`)>88uAh{y<@Z%sWe@|HjNcGgG5Xk zDt44u90!Ra{`2UnQ5mkJDsCvEwQhEdO? z``BS8>H#joiWr~eh>mNrg(LVHzoamNBLn%199JlZq=O;pK|1SdE0NTb!s&1nH{-xU zcNp3eXxEf&>)kVZ%v7-&{y^0{5ph7*i+k4Vj&fJ-itXN=`n1>*1htMMwpj#bX1kBz(eJIR(ZuqMz#tG|4x`knVWfkWkQt;f#0${?N$4F{48a@<32tx2UKQT~~DvNgmYe*qrC z+Da=chSKiHa#)`dD$E#S36hW}lJ1}!dI5TgQY_901evHpI~W6Kfl(!H4Rnj1)2K?! zBuuQ11|f<7-HEDAY9t;0z>uKnNKVRcqpgbZr{O)5EvY+_QGvW1 z@MN5GL@!)TIR-NoY>Gh>)P$av@cBQ!m)4999vkaW94-(Y8-26TIbmrWu1d({aMm5C zFD0j%q>D!(m+gm-RUlQssi-1I2F}QXu9^iz_Kccjlk|ybK)RR~qp&eej5tW0epc}` z@_7hE_*xVj1~D)~^hR!)vh*!8t{^gvY6${zTUwBxk6wYlh}WTNBu~~1Jj$k*h=a_k zX=u=msaV`{(Mf!EQ1iZ(K|=}9Q1(Izg(Z_^%{bome1kr+;LVHkmW)<6CX3&A!}_2W zRY{wxPxJ$&)i4lMqzzR?JGs%V^&U1rmpx1@mLT6T>za4Yxt?cHSb2oRqA-J#u=?j7 zJPn$BRp>e2+ENJLHs{)}Z+-Up*w_-lgXJVIf)M0W>vQRZc}j{KZRf;uZqLks^#fxD z53^nRSe~6e`owT3h>)8Tn^<_x=tuDM`lPLZn3NP~15ggSAT5pY1x#;(amZnzcrKf0 zGnUmgP2e-*76ygbVt%%$<=Gk3S<0QE=X3YBngv(x+kXjuN$c&EOI_H{Mqo%StSn9U!z_ugDk13}k z$Bwv50ofHxaz_DCr4_Jk_=HNcU$}f6FAY6Fd>`##aY9Rvwe~ zcm-!trgQKeLa8@&n!-}JQJ_Ocm4@PP7KLU3 zeO3)^VJN{%fB_}3(r~rFg0VALO8cF`P)YrHO6L*rwY|Hk5we1GpBIgp$+4z)C+e~P z@X6!LMo%~T3_=sXQdGK5s`zg!?)lQj@8V5l{?v)f$Ia198M*N!o(YRPyuP&l(cgRNi_Qa8R4k%bPgtC@8-@c-ep{i`nRjT{)a37-ttRRNeq&2o_f)WeXT3rQH7F=$IaXtcjvZ9 z;)xi?POjW<+gtD$GZ`Tqk5LvyJ|6I%K2D}Y%Ipi>8?E7#FWS&h&2oNV73G}o28r89 z-jnUsxxpgER+BE#bHbeA2@H`MEX-MdaQE?Cr$Urj8g*MJpwr<`vB7LV92Z0(i8;r- zVkb`um^H}B5hZ%qPBqUMKH;f@>n(8iDMja_%pDU4Ii4@q{6Uh~&AmH5@!UOM+w!b? zbLNkj^lvVG|2yX1z&a)T4Q8-N>R&Z0&d~>H#ET|aIi1MWfY8y|ntq}hiXz&yzLL{@ zau4&TR^9*L_LnA(7?)ip0&TVH$VtP-5D{5YLi!}PZ@uE}bFNPWF(jz`XlqD+pKhz* z{=5~2vf0?P?bGWXK5*jb?9r29RznalW!N|;DTJ`1H;%rFd0!cE9df0RU8YmjH|7IX zcHRb3ZyczE>f7628o%<(zk2mYsZv)DRm742^|`F6u&d1MB0_66OpY`W-`@PxXVyJB ze8})P#InoU{9_i3TkOl4S5*ieC(rE~(A$s%!x>cB3W^w`qXxNRl3c^XA}JzL4p#)Iptmel4#s~%o8fdeu*I9LWLOe6O4)tAI{Q@zG8%S)K+Ae zrVoDV{tW=uW^|!wzXL-=kBW|9Zd?V-At+k2*ht=%<#w!d{{8Hl2fw-Pg&89!gLhlQ zpTG7Gi^tDiGJY<5ExH8J z0>pva3Rq23$8k@8k|nFZ`>_iz)WgP@J2x_WG#GFC% zX`tpyzY|rY~GgYKj;t#ot>)r`1Q z%+Z5}PcSu}chyKRbXX3JG^U87X$~AcEdQ=)1W!a{t{Nh;7)J|b!51z#i5DfU{P>$n zc4KX&Qt#k-$$Fb#02@j!P@+vlVuUH7v%82j@kIbOMskVgwBqFJCl@lMI|Cq&@5yCN zsj4ehSQHW_jUV9`D97b=JXh*_NSw7idfc#4nlB~?^ysZk8#abJ!4oVb#^G?I;@Fum zjVO+oC#?(?;(Uj=a5VYlsL!H``&d_qf^{AchQVD0%03~$Vg>)sr_d&za8?0DWloYh zA-N0ee5e}WhUdZYz!UM5Z231}=XAutY;asfA6B%mZ5+ovCL#o(FPrX@3&+l)A{C;g zaPl8}RmRRTmWD9sj~s_|xOPL2AbRY@7&c~=$loq+c@cqXR z>umFgV(ZV-k7|adQkJ&Fec#+0KD+J_wr(38S4~{>CdR<_Q^n&gX=05X6@sTe!}~l>MJ$F!<3517 zDhROhh$Iomz?Q9zV~QcbdW92 zi7Up>`@Xrcg0WT-7F{ETjCkwJs~_Cn+nRxoE(}{0{0e?t{ZU`>nZU3uSpzlXD%L0zvP8dGs zCzjuB@UZ^iE@dw5F@wVVx^%+)?D7t{YQn-h=Uy-8n%&j=H_Ig6)7b+~ot!;lqBDb{ z#wO8rVZL?r6!NXR>@M@WW?fSkx`$RuWmv@n_~5Zauk72vf8OZntdVCkrI=OkU{ES8 zJYBbci-sPXObob($*jYG0pm3SAW^QK=UqN7H;kx7)urR+T{GA)w~$5co-lai_YE7H z9EgIaZ%t{;9zBCzgvt`3>n1O`ar&hqSj@Sqdz12`dKnCEo_5K9y!xY$?pUd)mW-Kx z=bY=X#T>(`{hQ26&lxpk_L%APk?V36kDKl4482*D4;vT@RS6J&1{H>;Cr?tql5P=| zE05jRz9cGbsPTEDrrtgK`m!0U+_TO#Ws`@GU62dG&Jc0cRkPVL32IAie(gH>$hPO% zZ=y4w$_xzY59OcLz*Pqe#>JYlLUjg0{vJGU3d<78)jeCKf(f~fthIu)AkTQy7Ybt1 zi19zM{4UoZ?m2qU1ub{az0qBYiZ3{jJsOkLBL2wYJEjev@N)M? z%uchi3t`UasdC|d`v2?l4}N{?b4(pLCLQ68ODLp+j-NQHu8Nq#az;Kb^ci`$Q26O#m0_7L zy)MvD2W9(@^unU#ToO09y=~t4Tc2P1u$`2LPPm3AXL7XlnN<-v=!x&2dy~_MaVkco znSnxH3Dq0$mfl@|^zxUU-?N$svLOHP;ay^9Xe(ed}PY% z+oBx8Ro$Ea@TD)V-cOGXW>|MkJ6Q>WIvyK6zr5jbgjt5`>i3T=xzpm^yr4ONSoW!d zd)IvX-t~{#sg)Uw5*pHFpJ?>AtF#cHynpqoAJ%+@EGFxOvaI~wYY*JN<*9u~4>-n$ zh5h{tZUqpPCr5@9{5Lm0{fQNyF6kFV%Qo0Zl}$Ibc3;%F~q*YCgdMVH#?qwHjHe|f6 zqaUqV;gT_#m#UKH$fK&eY}*#fXVAbQ+6^T~6MuTmxBqI@{fd*Ul*sNs9v3pvC?r)} z3#B!2_KIT)v=$;$U1awRqAB=KzWNWJTKAClQ*HUe#>aK)K5^5}i3068OAdJ|w$l#( z?3KUYaBz>70nXl>AhN}93|i(NGqRo0b`awLJCO!jO=BpWj| zxv5i&Hl;OsSc`RNAl&+jF3bAgFW>j2P2VMy$4>SB<*IMU*DqiB!$M<(lC}*4hOcdU z@)OU0#<4es)J_QA@XRNF=jMM-n;t%X)ReRZ{*XI!!FCMY>FUMFj)T+JAJ|Q^z~kXy z`ZrUj-e(cSbh%N=%X>Hc=JTH#KYSccu0OcW(ZbFlzT7^EFtM~4tHskV-PPM0-D$h= zPaK&rVbqX;L-1#Kf+(X2L&tOaMmEI1Gdizp@d{J_5@}QwLE3TskD@GIlM_%)pm_A zw*TF#`~Py){q!2W^R4YKtnJzQ$+!M$^qAU{@?>(_C{vomHL`~iI(^UK{lELd=bqTJ zT286^|NY8WY1@B&`GrR@4L@OrM6>G}1*TH&D! zGQ-3XU#iHxv(|+K$Qvn9$7p3IeAEI{Mb0jwqa}NI(fp`P)YCDrhr*5qt(xr9)Siqz zvwPKy5fh2U&_Qvl?fTwbF1C!G_j&SL{;T$HrJ+q2z>hZ3LlK0rIM2fhN=yNVskeN{ zbkH^^s5*loGI+XAbe{9))f&>cp>yTF4LXp@iN)N8(bfC6ZtB@i6eNlRG6>0QJzEL1 zo+_MEhmBi(V7uvZ{?d(JO(sN=unT{*B>9V_a4lnZrk--^&qMoB^$L07sT9Y^vGmnC*5Aaymubi|J~iIEh><8arGuv_iXRU^D>H`U=*zqNk&E4 zRY71*8&g02_OF^jjOfU4bY!AziYB$Lx+O_OC>|^(tW+$YR#56rvHHl&8VeD4c!+{1 z@}|kEUm*uis)Rzt=m!)S{6!27M(jl5-T4?`DD@ySN-IjSL0B~8J6`4J^NbiFntq&e z5E(rE31ZUUJD}5`Vy{hoNQhuj?RtiSWCyB*iV?q(_9#OC%n=m^*~sJqEOQiWOVR>m zxH6%{AGwLhEr<+=4nkN^H2#uq;Y=lx2tyTC_U*3F67obzkP&!WNwgBmd|_INluEf+?0N#b9rX!vU+J>P@gMp%w>VmZ+^|A{I9iVZDMsZMJuK_s7}4 zY9`OY0$C0DD-vV;TK>f>1o0Vc-_G<)DFEgNrbzu}#(M3NpU-kQ=*BoiqXcKEpLjFk zwtrb*mg)_=ZRV9OH0n8am~rpm@k2LGUb=AH9Gx+7!Jwqrgn*)w0&p*c@!lu7p&ICYk|L z(y(C@x5ZYJ{l?y1(p}TD?b^vpSTguWuA{+^z9`!XJUZ14Rm7!nGbt7Q)jWdtAWvW5 z`e~Pp88p;29ca+HP9HwOKtgC%yl7FmmyDl%$%MJv5A9_$uz_vA+d5Noiy{e_aX@ow zeOa4zQC@5+>M+Q2K260Sk&*qt6K_m_$9xwyDy(8@mT$U49YpcT9kh@Xlf6AY6)WFX ztUUR=xKuu6Cu}jimEsYljOWlcvBJ@oDDJ97IvwwtechIWyJXGKU6VyzrPZ#nkxRfn z+p-bY!^@E}Jtqe)?0H_soikc-lj=YLfUUhd4X#EG$%&xkOL3=+Lf=3C7JY^Xx2`yP z+%*EByH$)}T8mOfid_2jev=poD7I91nJP(RdCw80-(c$@wUOQWmV zubsN|j+s{j&>1`Eit(cdr;eHo8_Wt40U0;6j~S{<#?Dg45=y1uwwoRVU>PCW5 zzzarA#`gA`bmqNf2fxa4@tFj zoi0E^Z&Di}l#0Lhg*)PsbNkmGOmRX8hW@S2Dxcf4%JdZ|L(i0hz^+x$LS!)qd8c5eIEjD(Q1pQ>XD)Xi8M z4{XO4HNmn^RGF0l3{ar}aHG;x_ujOrLdmncR%xu-m_h*&s)~ha)+HMExdZH@%kDG? zcRKyXV|6G?$+?vRHB{meSRf0W*&L%@y~o?A~bPR^1}0jeYO{x+ zW9aACKJ@3W#D35!70J=ZTC)JlUH~7RPm^YR#HvKqF7u?dSOb_NYu-QaP1jAk7;pnq zkj=Y9gdP9ifA>$44(0y^Iq_X{Z@6a4a(ze%Rf<)g z8L>XM_TkOFy8@L#lrFK6NV{Lh2b~CO=mh4WNp)Vz4MxqGHhip(2Ff)LGe%CjVal?1 z&wo<@oI0frD;oMPzoLlIEEZq|^hYn>_njRpHIL+3TDbZjuKn>Fr(KLxEo3F}M&A8v z&05JH+V_{Qe)WqRze^QSgpcod8Ncj+NcvjkjbA830V8R%uw(DB-dFZ-K{QDD(cIrQ z<)SBcuReS-$^bMxH%wY=&u^AU*O5J|%?DWcZ@DU6IA!F-s8r5hT{Riuk$HeN=C_i?5XAQ74vY=Fd!&(7Lhc_SE(<~hh)LrI1$60`1 z^sBLKzP~r_Urid;YB#`~^Fg7m;PH~eIKK1f@^Nue!_#}#q}lDnx3;aYKj2?q_5;j` zX0B&P;lBM2VKeWko!AM3L$Z=e&`VpWeHcMnkMZpE+WJ z+k>CkyUw;3b>`sq!y684|COuE^34RFmMTI#Xve`lW^ul??fG1BI#6Hqwy77bJFvqA zJ$cG?bT!##bmXd}8cMF6xZt_HYfGHKQ0rrdELpK{eQfVIb@K6@uROPV6&-Y~+R}BZ zm{1r9Nl9ihmEp%B4ku*C45Y%ooqXX?laF!aTS13TArZ&uBM=+=6uu4i|><`5oTToHj4bHv5ZM*A=l zilVkix1N+x_fEz_KTlLMS6GI@BQ`?wq zQ8j1eT{bdN*PHoIH%qq+yV~K0sBE%)Cv40S8PYMp+L?cT$@~6z<(F6NS!>|*zQu31RZ)_eqjOg@K>#R&IU^@(zC$%+ zm55bmx=*RJLSu9dV20KMRvK=IcQN$M(=Pt-k~{FdMpKnBW(k}2laJxSk#Z1owa(lQ zna(?Jm99HP+y#Soh|@!GkmBgUL+6Z~kR=h4bmEk4(eCq(HJP2yv|(fGGiY*)!qM0y zR!`-HTS9(qZ|m{L{^atzW$l%Hn+(hbcR9!S$hPB$*B#hyaDq|qo_+04EPq!HAlr>V zutAUd*n}Y?OlMbBAyulb#bJZG;=~19aiOiHk~2H@E})!orJ+Pb?us79>zGn*J!)m1-r%$9>z4P z7z25mS$ht3+dbHP0(K0;tPyURiIZDfak~cYIeb7%Js`Wdu1!7`7Mk5A)5wFlja#Q) zWF^;vabX#fDeuU&c%I&x%~yry||`yyEPiwoe-1EjTtif(d{oixZ|ak z0K~8)j%2l7#!wy%U^;2~@bQ`gGexXMJPEX6?%@+ozK(0AiwMNnVbGgLm+|o_$i!DG zw5@1~^|ph%KDXw<*A8qq%&>dcH;PofkRx0QirHY zsi`5*$}$>G4v6_HB5bbDKEj_|{%+?D>Xah^FiXboy?h@nTQaWo8+P)fG1b%&6B{Wh zoX_uC_4)OWI2LZ&@Nqw~=&f_cPQQNI#Y~#crp8Z;YnecBtfe5be~PObF-2oArsg4@ zZO}?IywceS4&(yV2ev%@4_ltD-kmG}T`+3W`h$B)X%_KjN?AmY=bBwSr$MF;pYSg( zde7M5t-}jYD``ovNEx;nYgt2Aml&?xv-UG-}CGn%#e1Bd+T zRUe_w@IhuFaTMSG^VFa1IozW_(HT^Ao%-mKcg$;BcNCW_=&t|R^1Gom&@xIigMtZ- ztU{FnIe?gbWy9l-?pz78x!L#3e-o?EhZo;r3xx^B86)EyiV%ZTYTAdJd={yqo+2vE1fG=_^}pzdBbDB`_g^8kM>}<6~HVX zR=X#Bpv76$fW~6Z!grt8P5IH3xS7YHMi+uf3PW{S`4B7-m7L*}rbGQlPph0vGpJ_F z#35kO3ldcDK4IX);S}NDdiI{jcfBgE&sE(U6_s5)ot9PpXFL_Rka(9));>5c!IUDh zi69F#W9(H^mUhN99YQWmV^sA}Ph>>@uwV);w}tAz_RJ^O_wLl0hi&Jfy}x+*2hG>v zb4-EfQ*}&~h5+2ti&iw60RFmOSPWN6QbGeQdwddUrih~?#juFN4C!_X;X3L-`DnS_@6J{i=UcTcuWdk6|2K-(u=~P z>CA8#Te@V-HuKKNbb+eabas@&;<2-rO_0dQ#5|Ez!;B2HC#)+2johOx+cZyL=>Q^4H~;e9BH;ZJAK11+4{%~$tF^Lw^L-nhP|ef? zloYCZLx-MxLi`#Yw)`^Z$-|IcMEW6HcY0**j+3$|`;HtSWM&JBPLMt+^#%zTv7X$q zQcZ|C+&t{y={>8REB^k`Q;j!jcv%U_1^6bePnnOTX+Xo*AS8;lSeNd&*n+snH3^2A znIRmuJ3(1sz6i33QRbj}j<>o7JmCav#zox#)>&#zDd({cgTJ%uRR>r&?hdOZJ@iDZ zJJql!L(m$;h+@?^RAC{^H6n-sfEC`A9mS?@ORH0&1U1Q3)u6=svtLFFY z`T@S{u+!9EF=stv^b{&PDL;4dRk{~`pC%9&2CdL49`7iMMt)LyE)X4?gzAgqT_dt^ zs51chKnA~s3R_wzJFt{YlODZo9qa0@h{C6;W&;a5wEQC|c?v9|H;Dyku)0Evv+*O|gQohWg6e;4B3gNTdgnb+m*$)Bja>+*anNyWC#GFBZPu(*mD(OhQDCqm!@`sk1 z$KkS1Cbxsj957^I^=aD@;-Eh6)QAeJ0(4fhA_iD_8XqcO?xQC{rn4N2j$nxLg{Vv> zBI2+Vv);v;#s(EHZZjW=Gu#(=3K&4j$N(dt)%&;TQpQL=rZHh>j=ad&_0u!@y3W4l`rmW`RAwZXC09DuX$({4j1;@3tMsWe5M z3j!C9ovzQIiiYaS6IU9CCecslTQS5FCDJMtye2&fAQqjM7X@a41#oswdX?rV2*2XuB8H2Y>8Uleww)FbF@-y(H2!L)I@77bx5*| z%nU8tnu`OtZ1fDCf)oT`Kt{+5$Ia62X-slO!1iMdTRIXjrydXfK0C1g!H5PjQCH2J;{s<0|lK3J<8F54f zN|fGB(dZM#uFWyib*BqBAk+1xNlOh4R0Fvd#gun#W|i40h%?^&B`s>hghJ>n#~PwX zj%s`r7_2 zU*7zrA%zXCzj)aXU2{n4fG#DQjz5HzHvA-MH=PY7Jf4I`<+25TY1k4Plm8wSt6 zyzKqI`Rw0Wl)%Tv;h(6C2IP#eIU(E>mvQP0D`nmshB5N=X#^@)xQN^WA4n0Iq+B&)o@ zDLX%V$$PgP+U;a9Xr~Mv^KY;Gu*C*SnGPzjbG|#7PyiZTnb4LFPD5wRZNxQEVfifk zCr9Ko{#NQI8RxxvpnBsuqo%Wi67)pCiYQJhb$V&vdcwpP}3Y8WlA5OV>>+EZ9pKXOyON=lGnAPiha#u2@ z6XI#ZM!$K+6(zE$Qg4kSe&@x{JD~-aQ+{GZetSo2)*?PzlKEq%`!!kp^7_Yq>-o=U zSE*#DzW$Tt@49R5ja8Q#n6n*H*?zctw^^x>-e@-_3?23LEzhQn)Hd%yf4BaT-@WLc|1vhj14bbnfE5GvjjgMik zDUEM#eePdg^1dY#=8>(^BgJ9NG2h@z#e&%tD=(0*&`-c-5Q-HMcj4DF(JQlJX{^EnBO8)$fX{F=tSK1GmA(5ne%FdS%Gf}}9<7z#o4&c}=_Vpb z=t>U4-DWqRGuB7vI;Mg4kD*Er+dwY124(RV%|({#XPhl4VPgAG9DUcWLeecTlV*Z) z$5d^dinI8e2N?+PBt;RTw7gBZetG?)A`%yg+9mz1tt-s2YJN#%6a8!lK8V6lj%@Fs zO7jvHbNoH!2xslgU%&b_T1?y~QJE9_*Q<4+QJ|HIXhw> z;5Rov``o_uxPmi&07R5=XrWSwn2&%U!;^Ka6BYRIPlWXr+I)U%^D_*;=0!*+8Gs)i zWP$M3oqlcq=C5x24)~&$!viNsLYN{Hd8|+ZgS|(L+)f_*@`fh}Kj22QWYpJx^{<*$ zX0{#P$7);~Z&WQ>->^p$7u-BgOvZ)h002M$Nkle%Pg(t-CUyigvSAC{6LjSu7>Zg-S#)+yS0X#7TF( z1(pBvyW;>0zaTQ(Uic%GOad!(!PcZcYR9N}Aq`;?O<=k6=@;S@2{-{^#49~p2tVj1 ztyav}`_sQ_7Red?kC<@z__;NDK>@94{gjq8m1yzg-0x2MXbzuN*3%a9(9l_nHVU%A z(ixGv$nY*l6Sr{`^Xsz@brT$p1W8BZ-JqL3!U=O(E}53Xu1#VMWX2D~NkU7x=;N*F z-JujCW4Y*=+|!N`t0e%f;_1wnz*(^XEp{}8v=vUi$rPVTT{I_5N%fZEJ)0N~$VeyxYJPKk6QVC-#ItgWKUg-oVqpY8FM_)n#n`wprJ(F`%yd=)sG} z&AwyimHcrtbif;X$gwEeWxbbpw|_IQrEjO68&n)Vc?tr+U;x$a(=M4ZVxm==rGUY3 z$YFMS8n#5HJ7wf-s?KIUJfht>|E3uuCP)jy`hi3jM5Rp2CRt?x7#ON# z5QO3jYktNh@Wh_*R~BBMjt+>^gtf!}+)gYLfP>aLu*|I3y_%8j<{6ijd1u$beJ|`@ zeelF#>r*!LY-8E8gfAydl3A7)#PML%Lwsr?D1KXp3AP-z(~G&3x6Zn{PdIZ;ea{i* zujrlHENr5x_U>}2%7)&Za1sbjzvJBQm~-6+7T#WU4e!Y17uG&xpK?yJ zMS>z4CI7o?Kh~@aa9^QZdrYEffylm1UyB@2H6||r0Q7TZa?%wmOsylKXz^YX4XOIVyj>tIO}Htua~$Sy|NTJ{Go+$(O%gSj zxprEdHj_o$svl;n%f{qB#fTrpTSDge&fj_Aa}R7?VJ?e8|LEekeR#>+i8&$veE_e&i$i;vzcE#U#=C2>xxiUr|roV;^cRI2=G%!ST z?6R_9j0Ix3?OFtnR)q?4L&$$!@u^q#Z_Y_4mV(H2Jrsm_{eN-sdoAs^U;8}^Zf)qS z92Hn$<9>YGi`G@L+-MmVj-K}Omwn*UNiowv6BSyTXx#8Ix%+;E)JeHHWzi21dfZOi zpxrS)Ic`q$iYsfC#v6Gjs~wtj_qMNjyGQ2ZMjM+TPI$*VZQe2cFR=XUD@^DlLHYueiDs1tz2G z5A67p*S;3(ezJpCbZ53>l$c3GZv=icoOb*duYJu?LV>?E;~%RQ)d%k)pb{-QxqWoY2+Jskz}s_zdrYO)}3Yl`IM=eKYrz_Vs)}w>K?>&Bow{JJ~0UK z(4>I#>c>-@iQ-Eggf@}AEzWL=CQ^wXwzMQOM3hJ9!jQcN5|XM~na3a{5%=}{-#BIc zt7f=U8EBF$_2BGly_Z~S5S$4fI3-PH|;0T*c9R$7ep}$Jv5ud1qF0bG|)t z3NI;uzDS82)l;Renbn`vL;#Be_Kx&W8~}iKqnfk>J_R%TnQ zigY~1BJThcG2ZPbgZrw0&o}t=ubMS^XkjmsT1JH`xmNjgCf_2m!z+9u56x2^XY!~O zvCTNpq9{mvw;Y_-L~c9qB^a8xJCP@26NsS0kWE-rZxg|$Q}rd<7+Qa;?0vLK{q#SD zUuff~X!bJM;$@<&($iQ?9Wi14*qFR71l3lL9WqK5BKz?KG4>9F;V3-yE*dH#p9DU~ zOHe@uOf=MXUblcdS`bl`_zWTiRdRZImN9hBI#i*vN?NvTT|91%wPPq343c&ScGHw) zmye&vIH7B2?b3T^U$-R91{&wW>tCzopn{h#9R^k^{#S}N3pO4o@7diWvGDo zwMCIz_R}*874a8Om{%uCbQVozyuT#%*96ikesr^0S^vfwV~433Pi7)F1JPuHkcd#r zy>0Tt#9|FyYtLmEEn0dc4)ef9hZ&w294kWVp+zPSjf*du2M}`tV9{;$yLkM(4=#Bd zb|8f%(9ekCz_H%guRdaY9(3IvzNYo&ULU={}7TeYMnae$j4t9^x=EgJ`CrgF*7Wuwth->boqpm14f8K*ih9_ z7{j@2a}eOy2@o)`OlhDq2~Cti=u^dpZCRWQ8Fs@N!^Zui`<1^Dvry>&%JWuLI)e-p%f)lLe`{ii8iC66131(chNDUaK5;A zo$=2*XJ2Q%n|x&x7jZpO2jFl4b&_Ng5YjC>Ge+V=aKPW(d)}K2>u`XU0f_*NZ6u`dyuo)!)f)s2Axl^(J-u_~e}49FoE&Ha zh$SG)^BTohd#wHn3m!}3W#i_UXx?;ikGzTGZR^fw-~Jz5Xw;e9pT2b8U#|IPD8H~+ z2A{4NKlj-*2>|n{aj@X^-a9_t8H?Lk;`d+poZ&telu^hMPa?uhgq0$yg;vTL1zB_h z)0iQ{zkkk+B*5)Zov14N4exvw8UOvcdp@=P5!|Io(dP8XM|QnRY9Y5d;Kvrf{YRGF zMF>hCi&Pkb<_^_c{yZCiCZUD~tp}NYVAGSo`TS?L9ojc}*r6yBs2S;|k72Oodx&(~SBJz&t!E_>IHEPE&NssSl{ zm14cC7P(dIH=n!b8{1Ym+<|H9oyz=gF8#ozlNUFvIA5%@{rk~rBvR@bMz8MP^xG>wv-war$!6I% zKSmWn9Ws~iYQd7-t?r*#xTekkqen59lHlgZSi)Nkdg2K^>KC3-*Fs5Ak{SRLGiX*indb@kj@T-I%(+O?*$(4V9 z@5U!sbVMu+mhDT0n*u&`^2DF7e&Cy%pM`GZ1O@(fg)A6MP{*Fx zvGR9b`hsgN8~|=Q>c2eqDQl(x7ks>v?f>zqzj$)bS_ELYd&ht6>A#3{OYP5~ zxN)1mrc$oC1?@Vt*ZpIU?_Oo&v$Z?-tbOQ<8y*3J;^NF1?3zJmz`-oy?^6>*kYlycFjFP(J84Ex&dO@H*tS627# zFq*YJC&VmH-E>0Ca0Nk?C|UDe`Hs)}35vpMKC{&5M@dwQC6?KfvTQ$+t6!B!^I7zK zcFnh4pruXIQF@_!)Bkwka~pcLo|EmT(rzWU%p;0TZ zEe!BvS%$s4kVD)cFP};-vXdQbpD*lP*K_nBRfV58N%3eRNNN+YXnWojmBG@exq?xiA7`=PyYO+AFnAhofC} zCHP}Ypc*hhUIHxm(8+|p=mG^*TOE-3NRAI@r5ke5)%9xkCbN9H-)u9b0=(IbLgca_ z+U3$$G*w=pINIeNq4-e0O3p`RMmN66X%SqX*oYpxY1Z^?KWa@y9vegFuH3(gp%{`N zq(4tTs#$|pKh65C;zi@hkp+-)mAOD%Wu}2?la_yz&`yBP@@r%B*J6<HAc22ak0U(Bk{KF?JLQ00A=$ZBaQ4Va zi*oNdfJh?aGuWW5DTIpKiLKoH8_D6*xXaNQ+J~Xf)xsBPR??Zn%7C6K#X z9UB@r&Uj1^l}~I24bJD2b~C9cM1GN>D9%=(KYS$A_U{Ym^zQ_VeB_g7!DC2RgV4_w zfISjo!l`|`f&eGoH$Tg23J;BFdRh60+gl8Sz@Ynm=Zm zbH|L4;L#r1w`NTfP-Z0WVhdf6vJq5S8v;4t@);N<9Bx8lB$7cGj{=OEqJq zF?iL64vAZP9PAMXKjUb`DWmim?|1%fAM=E02kPZ)fFB!dP{Jf7}^^w0=^#Ci>_#q=cvgr2Z6X(lpi7zDj zqO$+7rSH^Yzj`2UVYeCdowKfqJO#24U+;!a+o)Y6lA$4IcvUa}V6$PF7;tB-SUp#l zW(Duh^%Q0yx6Qb6|E0ZuyXMUf&4V^0Y+|Jj&u;Ed|dYNn$1L-;C3YSnPP}N&*JJXN2gNC~PE0oOuR(O}Eg%w`q z{L=bIEtcDN>_FBIb*E+36{@@$$KNvj@{cXOOK%>9>Hu@XXV*UX#SM?@qL8g7k9NF6 z-l8GJ?Y!)F|OblZyiH$JuLpwkp%l1+t0vv#SHLjZdz4N9u`Sbyv)K=yQ8 z^?5uylY_HOmiqmhpK<_!i_siXU<$!9-$JrKE^rB(s=R9(BX{k}Q}hTrbnLLTe~suj z0D#e;q#oS*+_yJBv*F+ll#o=Hp@9khhfqf$8sOQHT`5Ldr-JRjb@R`0RNZKT%F&P^ zu8i|^lCfh5D)i}{uiU%#A=fO$BzsU3$Dw9&6|Q4~U41^1prQWXYd&fnFhx`R18+gI zd)}&u_3?DS?^$*Ki`^T+7Xf&C$%F;}_Ua!IO9KFVX+y269pVpce)`DCqwk!3{o7|> zTPL!Rb8KWTO2}4e1}EO|)4$dXcVM>e=GlGgXCFH#1BB0^D0k1gZn*^y!-!M>D3Z%3 zFaFzg4?eYL4RaQzqe#bYq+@iWj}b7al*yYXEq!Y5n%KG)T#e_>nO9D6*G#&>k_qsi zUj5DAeBpDBg1{!$|A|9KTGsjW-gS=L0my3akQ~Q03?Djt>fj;D248}G0|%|#zje&e zxI#&CEWbBTUcC44LEG0$nNgfqj-O|7P|Or%slz6ZQ-+P%ad>}qK2f3q+%jd^w|Bgp zk`eTy)^YhsW9tP!Tj-y^^3~s8`K4K-Ce!N=Z-4oxd*Ag>FZupRom$B%txkS()06-C zxxd>(ykhl9982!VDlDxd2`~yb-ZJ%~RfoHas@1)_zOnszNxyI5n^Q`nwpYXQ?Jdvz z{1bmf@e`>h_uOj_`=8$S%QA($(L+XIuUJhT6AKM6@I(?(wvhsR`NWomb|nO+ywLf@ zb&q`Fh0j{ft9ggtDH4~Co8`W98=Rx33asnYn{|8f&-}Gp$W&cXrENwJkr~ykv0E*x8?4_mEZ&h4P{gH9l9~2m<3>F(Bm;gRXhrzx7Xk zX8+cozv4sKD2lTZI0#83nz6vV@uz>)tf*0n+HU5*)26(iD)b55f$NHZSE zTLh&YNguC}ApNBB&RZuHHJk-gEl=X%6MYo3jbGdJqzkD+CK60s=!{Pw7t0JXGHS9l zP+>#WWT$H8rSiqx6VZJI9&@-g+Tkb_z=3^9V<>5q2iei&2H8FdC7&WvW3;q!HY$bw* zv<=D^Z1l^6Tc3T;f?J4JD{BK|aqxZX9&tENNZ2WNg^t*DtfP$Ns-#PizsjcqH+xdEaTqG&-OSaB*70~@C>h|b5mvLhX3R#mQ# zh6D(pb}BrQr1%Tlo}&i}NrEI;N|rXk-++uw3CCTNTPTtTkzk7zO|-KdB7zAVr$2gw zfxMk*fk|y96}&ntLS!)1)9Gk}vWVO9Gyp|gy`2Z6pAwu)%$aTgCRr^E`5B1X{t?;| zywu21^r_9g^A{XQC&-A_{so3Jo{SpilOR^J5tKyJ7huBjDd!mx-^k~gOu2BJq7E|* zPV|c?o|6OO7#6W~PAV?S)PCdad84L0y8T66HJOj>`9CQ3r=+q8?m$A|ykP(%hYmb+ zIcf_}TkYvlTt8*mr`A1UaFUwo}#~^$SN&T|R!Eh`3SFy}`7IOv$cP zlK8NdgVUaH=(eGO;)Du9NuY#Jh&7;GbA-I=Gk{TGXDBD09{bH!9oS~fR{PC}sfw5B z#PA(JaG2yMT>cl2pY!;RmmFGLS7XNUO36=D;RYy3sFH?J z(Fr_t>ZYm70z)PVzOZp{WvnO^5v%Lf5Ks~1CAg8Dv>NhB68=Ki2nnBJxQk(;tTL^7 zL0%b&GHQ+G2-(qIW3!-18DwAg2N%4>jujoJU~NjL+=ipgebTI# zJZb1Cl?Gn5=*kHTEP*Q|$4(pz!LllE@X!w|yv^0Mj`D*Xr*r`D(M3cdg#!jG9y9#| z^KV%=ZZ^wDm1S{4@4^B8?gwvZ;LySia31WP`enXx373thh1D`kJgN1lMUNcEl0ZnzH|1qrp3Oo zP**6NQ4?aTWLb`$wS4CDr<@|cp6-cJy(oHtQiB(wqb!x0{ zwjQMLt3OAN$3V0*hi#n9V8>1H1gewAo#F@&`l(JnOdyWv6Dw%R2R$|}yl?)kj`((w zyus>>N#j4b@GWCgcyORIiSNPPziL*=;YeN|JdRe7;bW&pIfaO=Z&sGCe5S4M#KQ5j z|J_wT>ZB?`vd29Ar43K8iB)AoI3DZz|G>hxs7_+pXK~4-ML2JJ(nH&xUmq75jj&4k zs>w^2j-T_18-Mnh9j^{?R(B3zG0w0A0fg1b1XIvg;;`XCb{llgwrwotAlb_E_tJQk9q2f~6Wn*Ws zn<+EcfEgM7{e~yLxc)KXf(*we-Z^Wp@{;c_DYUWriph)B8bw*+>s@XY?CD*vuGqbX zvS46%)3i(NifC$DtFQ(Rwqlq$CkqRs9dUC6->4g$#2IAoJ7P`nh=~JL?8u-3Rbe{o zKvQk(lyxYr`kuKBg$cr zY1Iv2B)*eQ>fqUJ>!}b(BtRei+|oOpIoqTF-VA%_tgLDE7V32BUw!gVyN|`)ze5KM z{3lEA{Mk$27Y$3+7O`a0efE#+dc`vFG=Vq`<%ku)yN-2lU>45(rVin}ed@(dE_8Hk z^`9f5zV2U8Q7LZh+5T^z_@mXmJJo8b(6$Z+|K|1=8~v^iH9V^s_#&R8B$fbNpBH(G z_>Wb`B+Vdp9)=tv0~Ricsnha4f(b?9h@{S3!pLJhei} z^tf4K*P-suQU60nj82Izz3C6|Kh=ID|CnC8j)70eq+lsjup~t%2Md7 zX|=bX@TyU|wel4iOrA(m^}rS-Yi_D|64bV9X_LCq#8)>w;VL9O3!dG_dLP{J^4&c* zxpx8v#8=Uvq=X8`iV5D_1ZHUXD2GT<1>;j|?L|2;ptXs%Nsi+S>mJ&1^uXk_@{8hA}cAb-c{4Q>3W~?Qteog$LIg#>0dQ#Qc@l`TR(38!G?~fh{JUjVBRuT zff2?3h#Rh`A$5&yd$hCl;7**6+@_sJ#C5&9#0^AkD@#W@7ji}t(fEWVU0sQH5}Bz7 z%|S>SQ8FleY<@~v3~^D$$lwTy12Ue7n_G{BmQTk!a@P8VeyM2DCgd-Ss6EGe9rrH^ zw6asxhPWUsBl?q#iG*4N2a@7&;VH(#EtYo#CF6k!DrIqcQFIWPxzJ;@z=C|MA?9?c zfL(|7(Qb3b#AU^SPpRb-LNSZrhW$e~VDrW69DIC1O8#S5y zP|YHf5i3wuHWNQ8q7*8A_+$xG%E6dWV-*EZ3oJ0SqZkiUrp*M;pj@vL(clTVVs&4{ zN~m%jS?(y=h7|?#J-=InnSRAbU|V!bfHEJgq6tiuVQ*lV8^xJg7VrEjZaJXRG{-MY zOkvA%QvAq)Lv-f^u@3RPe&QlH)we>$&e7n19kNMkq!f694NGTckBWsFl^t*H zg=1oknDM5hSgH^Hu1pXoa!7FN`k{rO#>gXV!Uw_51sTDRQZ4Y2Ygh~63{a6 z=1ogtRFUC%#V$TKn4nG8wX_Cz6I5}VSQ><;(4F+Uc-(AbY0RQJ_0M%@mgI%*#k~ei zAkPd&VJRr|wDQ|39RyUVH3cfJC?H!rNp^{+`OSjJ=rIl&A|m#Me5AkOW@k=V z2!3|?-Je|bz}}-hx+se$&ic^ex5|7cSn)zC98FrCNXji0MhMAaE}cx2iKhMr(`dCt zLNRtk+$+sk8p0_%I9-ii3rQy72*mf!yXiaIR~q0=95U)HGp}@losy|oO>#b2|B4m3 zBo$XKSVgJ7XJ4sXh(5IFcGtv!@666k(=U6+p0#>zHu#{2nV@nBHVG^CF=@a_YO)5zEBX_5B829Xc z!klckG&o_W?ZnJoMWdl^+InkE-Z}S%7x!)4a9}$V@$|7XKd|74gC#`c-H4 zDsEfXyz6O%s_pTQ`S*LNW(bu-Kf`@*vPEdBA|b6rUseSs%ij3P{)sySFD z|Bzti3;Wg`TB9!!?YI%V`LPMZ$Gv~iZHB@&_ApK^9y@EnxX{qA>|OtY%MH4^Ea$m+ z;zB|YNLnRyUXDa%PR%Vj4pC5REKzP{AZC2#iY~L0~dHMy`s8dm;8`30Au--lIW^016PNGZ3&b)TYMKrP~eQnO@7WK^p$#qjNhNo&;faQa*WKNTSCF6Z6l5fKh zmvXJ_*=)jX`M8-5X>?TUf4cU^zq9jY-DW4ITsCPj@xT-CZQSt}^2#!jN>y=$fMvmP zr2cEcR7B=k3*4yY9F!KX%%jFl;su}+j&I4LK$UtShR|$U_pN`7(iF$w{PKzO7mb@! zLfhn`F#Myu`%%s0xhbc;mgF59sZ*Dh#$Ne1luv@93`$X1Vf_0qe%`XioNtYp5L-}j z^3c&kB{+QCDqxv5JdjTqI`Yk~4!ZJ(#|<6TX;jn$d2aWrPptU#^ZVB0{^b+q{rJ*5 z@0fEve>FsM=VJt%rm!s+)EIDEI^^wYkM84#Y6L7@GVJ~r*VQRYc$9=f%EIWwDgmr# zm%F`fRl|oWjLsrK33Us3d0N#vXVj_pFSuoD+vZ*v*YDr@m#=>HzK!4Aee?i3s>SK= zTlf|WvK$=JB>C``XTP%PDU{PhJfWRBY>Y*Zr5DmCb`t!^(mRHoek|A7R5dsohsr}J zi*K3J5O$|WzPx|4?gn0&t@(w^KKPC~*JEyH25F6+IDtG`IXnrwNUP8Tca!wDH$VM9 zUcC3E?oF8KxZ8hq+54}Xddaj=lfG}%Ek%PuY*mA-W?7kq3?Nj)bF-<6VNIh0OsIo> z$D*(#r&FySGUs-?do9~K5%ny7|KGe%BQEtQ)EB469`?9EdzcCIZS$$_D*O}YNr%D;Ec2O~SqS`GX+s~@;| z`eiI*Fn~GllU6(A>2WDJ4v^{K7O&n>Qw3Eu^L9K&C&I{1mZ7A{M^Y8={3@su7*;{G zNT-t9d*py>CJR1gin;avEzjJu?qQ4fR4t+Y32q28ylejZC6-J>d$b5hkwVYvfbKQx(8KBo2bAmY~Mu7U0@{p;7haoNO$Ge=LU z{I+7X+Uiy{I~y$@y}1AJ;^(&?>9HC{g?zPV+h4x+4b{w4INGF(@?v#yuak#z#NuM5 zE3l@67oHh0vwwPFsWV-t+{vbBI*BP(ln=$!Zp{KuHr~N2=0`J9K}|}~Q@hvPyY7+J zDcYxZQaUkz&+gMi>cUtM*8mU#ZanhlmKpL

nPw?K#v<8Iu@o4i>9jR8GOS-U&@` z`D;}Gi0BS@XDtZ9QyQpjKBQ9z(#4a&sA08J4KN2JZM5+>gd>Nb#%VPk+Z4wE7`nvFxam7b zpl>=DrqsYZz{yFW_{e%2i7!ulo$h1ke-dy+c>`1>lGaOpWYE)zFnW?{aAM#wn%#DI zj~2c&7I!T%DRzjfwonacz$mQO4s2tZ7o>18ZTsP#qbH6StsxcbIL_o=!?3~DQQ5_J&iL%vJjrA5C_oLVoch9jy zbv9^cp1`PMTaWB#6~HXhz65LTnCY2Zs}A5=$W5!k3F{@P^;z;1N-UBL;Hbc9{qw;t z9F-?&i24w_msNG8*+(;YEKlUpgAcUbc!r99lFN4 zmQ%EGX9AtCOjEk8EN6?8+|z3yJ)uf~457WFIgPp+G9$MxIpIFl$CmQ+4r~otj#`+S zgR~3?^zcN!bU-ZHI(l4(*=-x@p187~e27=oI&e}i3QO1oz451i)hr~jtIPJy_s@UR zAHVt!`=X6HcIkxq@1A=De*^{990YVg*9R8d>Lv~=#Hb2o#&g&pJHf&j9ZblvxUE(; zVycbCZ1l>lQ!l#BbugztR*ksM_&+`Ow~mQcj~s;f1M_dO13+Dhx{;W1Kw(3R?|h;@ zr!`NnZ0L#DosCDj`(PQAcOLH6BqG(c!QA7M?3dH<)`;AWxSv`2E>pKfLNK;JkCsp) zQ+$w|UQ=~`5=Wp?`DNcIarg=L&l6^R^|BZeEFu$H+2N37a0H@W1+IoFD1=mepRua}^SpMl(mCzcz%?EcW66+zK+V$#F zJ73LZ7E%9IHddCoV`eaBfR7}_S1+O+3xzj$(4b}GX5T#R(%LhdnFt~qV$SEN)E)Em zE8qDehXs&4(P#nd@qT>SU3&a{=n)KIfB%D*zVP_Ym*YbB9B2`p%O=ccgjBjx#2=#n z?5@=>?pq&*injF7-Le0*XQ zGutH-7h=AK(vqWVCM~^k(jsYCu>R<_=dHrU>d zBzI0n|5~%cPK&TX-~sg)NoB^cwRYqv0sQ?J{8)~0h=We`Y@D=`olynD1V`qGH$sL3P zH>JYgdI-IRFpKAk=KxGTdiR%=vY<$8{85UKqd{HLd^I$47Q(|D*Bi~!+-Xo_p~Yub(?a#rhCh8J^!h#y}RR#ovu?xdbSa) z?cLGpQ#ni}M{Y=x7b<+@;1RdaxZ=Z$-l|J)GJq9CD)!z#wd3Xg_41e4NVOYL5GU=* zZM6oKdT|&_=Z&4=SCzAZzOeSe&#!-M=iz-L2Mu2~Va_jJ_90s$Zku)0ZC!Ct(i?fC znDy!;^ZJP6!)2d5XveOeyp)n+o6)|(Lk+RQ>(3_>uq~8x^=P7`(u1Ee{iVnMVC{jO zRkPJc6=~w2QG1UcED@EK9)#}hKfC0;4v&-k6W)265xx|E@|3G{;4 zNqv&7Jn|Kj5Jw4<6P;meD$LT+^g1IbO&+XH{-3&U-NTRUcuBjB8^ppyq_(ts-{I_~ zhf&JtYxuxnJ;&>q-c!4d_WsGMU$wF7!;9ah*Jsj6TLGJ$!beY?bP1!*s&a*G$m#7x zar^&o@4VymysA6@jz%+@-e)9Dk!IA3C0Uj%cd#&y8`#ER@InZI1aKeE-ml1v#xbWvvc@c|%_2<)ML44ui}y!6b5L7k@Pbv^66s_64qWl7A(`Ymxn`hpmMDmuP*Wo_$dD!Q9PSkGPyix_cZ7gHAI>biya-4XwE z^#YIMjHjYvJdrrk#nGH&924)GHFZRkX)VH~KEutVBnwu^MeG}>3*rWes*MfV1M1opHV|?_IH$E^37U-&F^^v1E_>k zCrW7CZ}UswS2irN#c?spCqns%CKFx7KuelX7Czm%04S8N!&YY+*^Ufqp2b=CQ84GLn$SGCNmU)0P+99V|sI@My z{A6!4tJkQ{yq+d1Lo!>wz)rr*E6O(5kXo8F;{#6j_pS?WB}WrvEjBFU6A3{@$b{f! zi<(=LFd|I$Kt@F1@>O%m5t>>9=5U7?5UQJJokmFIWJ~CTDJpgBkT_^z2F7(c6UlM> z!Ht{m!V^f|PN7-M#T_((lOPm@s+Z^hNPVqIJ3Z6i{E1c9b3m%1cwrUj z1wC^sW`Ul$^d}~cch(|DsAqL7RU>C7IQ96P={aW;5!!Pe5W?<;u!X^g+(cN1JI}1j zTdvmJ^?M?5rl*NPw)3xu;7v@h=w?ZZI@Zj4R_S6s^}f`BvCNa^Vy7-x`QLVa=83vJ z9A`=PAiJT_VS3>TOG&}9^fOhLU%B)Wea$K+c%*)Xq|U*f*1?W7Iw&qk$cY5N)0G)x zeDru{J)?Gdq_sUwYx9};rev8yNS)exM`e`#;&4O9t*xGR~Y@TFWZE0ObsL@ znwRZGYbp7JW~F89F5hmZKdoJ^>uF+@DZ+cJ;|$l_yr*ov^4CsB#5Bc@V>U-)T#>%Y zkg%wsza2{;DvQUm%%Z#{xoFRqc79s>y9T-d*j=&xveFHRmz*WKDS*}hxws-nBt0&p zJ<(Oqxd5CGJv7|MA}K5lQW7qw9~~YV9b}mc%Vm_kmeE9nakBPocLTE^=d=4k^W}v# z;)O@M%O)E7J2>kO{qd|vD^}-fpM=Bk28QOMWtTUpkf&_P1!l`|H7sK*s?J-E z-H3hPqF<=z@JM4W9NYy2JV$V{h=ziW4+QB(vXle|m@y0>l<6Jz}rVK!~(FFps@XgG|jJk8{ik4ModPkBfzdkzNNG#%d;Slu$=j+5f_ZTW+b` zrFz#YSEAGYuw)S!_@%)63Ao2QYX8@v?*R{mqCso+(=b1%7+4u&tj~<%tt+mwh7r$T zWQe+h8&sUdO-Tdzt@e|Dd-QS6tHhhlrYo~q4#u%u>`KpHp6zQT7IUhf-|&IR&O}5P2oD+G3yuKS~1pY=Wqks;L;1Awj}L^}Dg znpfvx2Fh&Xn#mxuf6bvagJPEj>!Dcux~Kg#%QC=Drl#dpz|{#|FUCd*om`o_IGx4p zXKaT#u>d1-YGa)}Yrps&azGKIfspo=ycUO`Ev)jYl`kE zRf(4en2IQ+v}0+cN9)5#{E25mNPP9+gFmQ!4Y|?au=t@Wv-q={?@<5Qa^Eo^BF<5@ zbQF==rzX1;nXA)eg_*5`Ov*c2MFGf`zv`EcPq;Y2vBlq>N~Ch}pxNDXC}xO5^=L}s zOmE9;Z6|2WH9`YD-669wF@p3nHt?ZC1y^*|dBX=#{71J&Q#95g7T8cwGR#V*hMP_( zh04pSe-aBHnKv|&QB}l$Y-P-ouFNlo9(~73nhV0?dZO-j>=9%HFr(wG&eJ5vHXLGQ zq$bV{cAoBT++z2~c}@`Pcy|M>0qa)LKj?xI41;h1zx1`tN1tc|?UJhtDn%$0;)qM_ zhB{Z81EtjkA!=koa!PT#BOs8&y7zUQ!FCTq>4l1!WC5N)bmMAH-OB1CqKLH!5$!)R zKi$)`U-zVCVGD(wu~g}nQLc4NqCu;7kvRv{`PmKRmof|ds4Qp+#fO!p9Hc`r!v{Q& zggqz8?VNJJIF2yV48KYvk>CIvQ+lUf-L|*wZn1a-?wY_K#T9wt z(W8o11Jh3!lynF*j>X+Z64}pRNU&^!0p+F(8f4O#hY3kUGa!-0%&|BKjgu@a@9b2RO2B6(Vc%LUvnPr;e(gf+Vq z5-1V20JjIu_6DuDz($)&EE9bpTQf&APG$~@`+~&rxMP+#u^ciU{T$_w+$>@O6nOtrt8OF_F(64O zL`FoX+rhV0WcaOI^7{= zZNiZLDrm74Z7QsxSB9J^Y;mN2JaDWV1x8z_nL3j7R=e|7U+j5d#S z)>0m>Tejujt+^2xy8Ur7u3f(6_qKnWMU3_R9T_DA+&VdG^oW zdRR*e6S7GHe5kYT&#wNJU8NheC|Qe3##qt!)qUSStvjVOT831m2&cI0fo0>#hXYlhpU|N6+IfBW|1 zjCJv0ZwthLH7X2XhF{+0*`>d{<*rX{xRp=N^YF!DKzi0VB~WFPhssg%Wyu87iHn$s zb8J9j#lbl2z(1Y$#S}B63^H|W5Ufz-=n9r*6l5=%bdu|QF@V&pw5ZR9jG~<;j$c0G z(y;w)C%&}jo9BkQQNc(0+Sm>Cn_KR#&aaR**g61f+!9|u^bkh~v+)G9e{$%1O#U#R z1`<~hubBy&LOkkN*VjVU;tw%&R5$>fECe|b|TU zy+05ju}lP05mC1S%s@JR>IMEhq6!!3h9py`Vy~cb+5QpMqnmK3#B< zunqBWF9DFLJ~6Fqn7;>H&?9q;gly^AuU_FpYN8^MIMR9cNOwI20ByiX_~WJnFSZ=P z-&K=0s&=sL1jjyuh@Kmt=6P`8ub)Zdo79IBK?61*vjMwCk-a1tSM zxq}jgC!;|KfE}6zGG65{$qvI>=Ex|wU{0f7+Bn#`ul0DuS45L^S`xQMzDgm$6Z%1w zRRN;Y38pxOK5E$xch&7{KSMPETq(fe=U?NT)%i%P0^l#wpn18R0nP8GE7>JuaXANHl?j-DzKe zj|t8Ierm6aZq24rDA9zuJ~iy3zdh$-(c^NDyvZ;&i*jJPuh%Ab(`_fRt9S&4gT+uN z0=h`OKwV6(H}to1HDkQBiNi;3OP7~;RNM=A05Thcb#6^{@R3c()|3cOSV0IKAHuBh z2L|h|VW#Z4A2gObUOB&Wx~79hA#@6}-iF+gqeiFaiLbZJhz@stdKN3xkejO{C9o#D zjKMHL_=xr(1dsDRk)lTqPap9jWEC*ull~itDkEH);rqOJ!+<2(&?owxB`AWyVbX|u z{Pf(hjJ)_nJ$EK?;W}i>GdH}mi%hvb6F%1@k85xBXIzH>kH{b>j2`?>B6<>LH64+M zxq?rxP&^1P#}ETmG}1v?>5Nrmb81aMGbM*ziEPy6WJq+{$TL`Q8DV_jNipD@IjW3^ zY^CL0Lr>M-VT$2z7-T$ZcpNeSJpoCy7)+G2B*O5CaDwnG&soa+IO(#yh;;hL2C)RP zJk3!W8G)QgEO3QPg~{p{NK%i;b{c?>qC}C5-FVdVxGkn$USpgGYDVwrNhFC+$_!!y z>YVcFv1UX*SI>(qW>RZ^Bmg5cR7$7&qKWqCun}iiY1o4=3hMb6XVv8DePgvD_Y&Nmj`^J`p(lkv18$Cn%hfGKGj`pw5tN6sK-R$E) zkA1MmHWnansk-85XYEr>`zc8DMM3Ma1U8{NIDc{NjoXUW02!Bnx4_O|l$<#{ePi3m zpby50q7VZ@{^+P;4^*+E|2#hSk(z5hy83z|(o^+3!p-y9^*6H-`}MXH44JApS-{S; z1GP7LjMjiLH5IomSy0F8Jb)vFPPx}d&O7NF2{wq0N}DAey&Oh7TE`P447mx7s>=v+ zc1J*`QD->gl;fMM2%ybL1!0nY(d`N~dpdInontYxvP7M?qp*g1lE_i0q;Ce6hQ8K< z42`5+C~lVEqW7m8-oO;;R4ZR%^b@yxcpxWDR~r+tBD3Vi6}vb~$9ayJKo;wAxq6Qy zFJ%B=%)oTQsh-9SMKy@VF=E!sTD17elGPj~jn>jztI8~3Nj~sWP{2%Zbl6s9moXK= z_)V#>crP`}H7QCC2iqLCXwif9_Y91&%GY<@3jvT1wTxBvv>rhP7;kv?VE-)7D*C{R zs~CB)Mw%5*)w#=|8EhN$HycNBKf_;L{RLlJ>YIuU{ zY!){Uc3e`h!p)3?67SqVC)weX6UK`f8^*_;I=ko1_7j6+S|7*Inla(dq8f@N^g}k8 z-PG5fC=~`Cmp?NToZ_yFml(t1nP17)wcmc_J~9g%o5aqVgpncErr5-~#nc>$tY2}l z5OB7)ZCk<0$P)@#0k<y?%(0kB ztrM&V<65AKVXeo9EM^JczkEAc2vw4!8H>=r$Iia=zYjgkah4d+@I-c6Y-R0$Agx;k z^PJ@f9&`fF@0|I`eb@d*jT_lQCSm?qZ)0fCSD&gXyM&7s9f?C>*J79Jt8FLIGnV9$ zB6kj6Q+_F-u1u1xiYOOfw4CW{VeuZHV6M(Cp;$VS=*=+iXitM@Khbgg)+M`kE!z|U z;24+~`PQjtSw;v)C{x!^UtUJuRm-v!sp>l^xX|=f-R= zTSwAPe1tRZP##(o-Y%R_M2WQpl|T}mpqCo=|IY&tG!1kbJM3-a@~34d8OkyjYVk2& ze7yR)WT~^(j0)(l-+JU*C!Zz@C|5|BsYUK>Bx|VJAQT%Wy;hFjh)D8+%2^V7+D|RZ z;_hk939%1lea`Y@-HjN8{6-k8@H>iD)poTpKY=ibPHEwY4$gg1yBd487OXfBuG)b$ zO6Dc`Rj;<4z|^S%Mj2-97-Lks`x{n<8uzn^`9E&`$Q8@BP}5P2O_5_5-?dZZUc`fF zpcfwWHqyPEfC?YV-st!U7gDk=R>w<(Qb5Ymh~%UEiX!5TD4#t0YBD@@MG28sm|Pf^ z{0)c^uq`uBhQwTkK{N*rMVk5qtQjH;4q${g{un6+WkLv{03qX1^zNaaC+c5k5j~lz zx;$kO`*aSspF#-eUmR29M#X80540ZJ+kTSH9z{qJlHAnbJ4M0U;)Lu->=AL1BSITF zh->(SN@&B9hTDB`plZDTweHp0zE;YZ`3L!iTPf--mM7;Xk#w!;cTYd(WsFY|Z$L&T zJbV1fYG9OrFboZnNCG*3*;xf^%zNS8S8j1D_*>Zvde>@dQvGHN?1GgDJboOO= zS^q+T^ZHz5F>~QT(@cD-=g>LWJ21lG7S^X1+$2cQ8N8LAoc<|jdnSDbMPWMffOrBN2~pkQJ|4jlLcDA?A%6jWOLV4jsO$%0QeIpji?q|@2Cxo0R)AXh>nnV5JlgCXXFzDQ&5mz7}rDX9YhSU1pxZd zpFOx3r?P64bH_BqNY+Vuf|H(VaPCyvsQa|a>RMRvZm;I^l zsoIOT`=~#zC)8s93f~?_NxFWT87&OduM)S4S&0IsC0-#$hco#yO3}h|>=dawT9~Sr zQ?=RQ;vliNC6r7H{GNi|LZ6bt(2Eaxj3h)~lnSLNm~2(n8Kufa!FwEcSk~eppdicn zN9fd^^%|~%rr-IJW z1BZ9Ml?HFiba&G5vePjl*gPpeQd1~HEQ)21|9Xzlsm@8yT$ZgNhPTy{A0zXuB34M* z@F8FpPh(Ihj7djmauDl;@)Q0!efS!smX_i{qzO-y;Av2D(k+(1h4IaRkd-KG*~H!QWb$}L=k(eGS>P-z+ArYPhZ0HA7+(v*b3<1eo%@sS@!ptTErl$(i z7qK6fg$`2^1(;!^H73do@X&vYl5>sZUYO6Vzxmszo?|%(>&`AMUiC{GJ_wBU>;qV6 zf?!C()7&y_xmIcXV=TkE+(HVh)PlJ+NTm%#dTxfH2oVvg1Yux^0rK#KWoHv%0_*;wiug!dCk7Ns1)BIltA7PM@5HpOVVL%TO$MYd{EqDU~)Oz&^@J>R?l_iO$`~Q@S)U zzNK*GhdEJC4@n4YexErOGs~p>^vs=wHJpUZco#n5Dm5`)-``T4RbbVH>K-m=r*hg= zyvF!}WgbD2J+5AO5yVky-1>z~VIBznW05o9p-G+!Y`)%nv}2$fLyjvt)ql@uKeM+!KnDZnnWq}|vJ(*>6A3iQ@N@Udt3mE~ zhzl_X+D~I?bQpv{Q}9&%UIgSjFY%#vU|AVE1F58eXC>j9{3@2nh)YR)=E6oQ0I$re z`0u-Z@j$EA&2ZNoLP}3fWtAhLV8#k{(~2u8acJtP9q2sGh6(Txi*i_< zQ?|JX^|D@v)$U~(1sQ1>Pn|ndV#n5^pbh0=FV)DN^%vpzw)>Dev>)^!WXNMnA_8A@gIL$zcm(ih`++|J$FfRfhag{|IvRTuc@aTKTX_UUioX=%GSn{yAU@S1m&J77Xm*gn7I`*&rw9F zju4IYB2nhOM-zH7Y4vew&~2OWn3{U&tGWlQN~gY+GP6Kb?LMtJCmBTwq)K+$Lmk5( zr&AD*q|s&uML+@SB!P#AAUYU~55Ngkjx)%A%k@ZsJQaeXbOVQ>1HYvbbRJ*?Zzg|G zJ`$zwe7W`b<7ZyHdF9o(0mjo&P01wZ1VJGsMo>5ag+kgZ@IyU`(q>Wy(2~r>V~}oS z0Hs@XfN_;Ic`*Ss!n}pc8Gkpd1Eb`v2X0-d30CFPq(ccZ0WE)=W25FYF~Pwk&z(EC z>C6kC*>D?p;_Mra-~|oNh>(PG_ApP&-H3(B()*77klG{?GNeX1h$pNutA@=zdm>xa ztJqVW$Lj5e&b~r*NmYx%i5wf4!z`rZ zFL;0K*B}*0R_Q1B7Q`eZ$qxlsSO5{v?+{AG*W(*bcM=#mq}F`%rogE4W1sF5A_;zD zsDh-)RR047+OV(fq=Uv$MF=Bou7Ad&5hZFgj?|xxBETsh_taad5Zz@Fk%157>K)p( z_33zxLxU8jlpi5+Z83`~a49ASm6hWcN{^!g}bdq99ZO=I@{t+)E zZ4^Z)#WH&lqF5qcP26Bpe>;VrGDZ|?hxXxK4*c2E8j%JKMLoTG?eLo@%ci!Ns3%TyuYa3<0eq(6UR5Ee1^?U)QW?mNXD z#&VHP3FOm~x-eAJBgcKpvox3?IdWRsWcew@vOmTH1aS)yQIa`rVi1K^gj^_`(T!~r zdu9~Zv(q&O$atbIsL;og4fKeHixcL&n1ul0Z!F!=OTRJXLgkw0#lUxwnmgz=J8&#Y z98=(qU~ot@ru3ZAOPk|pO@k3p@Zf+WI{frtIoS#r_aT^jOq=@K&~n^hqLFVN>~0w7 zR8A1ax7(4+JWb6sh&FjzHI*n1%I)>8g z4EFO<&xSll063Jp_9tx=fF2Z1(1AlPR|4L+5zs;y$k>I z6+nhSm@n`l6(Db0api%|vlt`?)v!=IYE`=~&b1bWF5jBG^7mF;M%K9M;~;f^6J02b z9WFB8QM&&5rbDcpVqiw)%@H*85>>fcpV_2g;EVtz8Dr4Q8;oi&U{cf5Yhta*%~iWl z$0=N(XC8&*5eV3LLsEd2(U&dYVy2GXJD&8ct|(c1W$AkG(6NkTo5Dgo2=|mw6R2LS zjJvvYJx5+MaAJqD$Fi&xIi${lk6S7(WA!Gb5vIWd3^5@l1}rBgQ+talUq+)LhOq-4 znDPwuRbX&!L5jk7Lpg5p1Tm$Cs|KJUNC1c_^gDf)WducFQTADkd463?F@sJrjPVbH zMl?pl12kib=3|Xb=$r}ubQ)IpFko`0m>pLS2ThtVCBUCd@SF(2^{brmA(;;OHN&Qv z!sH!$5HysK9Eib5Cb?c(otGpa7Gnmd7@3&3a@m&O8XteM{&miWBXu&BS+Z>-TnDZk zy{cs0Ei0}p&diT8hFFoiW3U^W5I##Y3OHl%_LbKZr{(;xevfa(XNzZjUmF0BDo&Li z41!i-gavu%kgT+=g*AQ(l(O26x~4q4m=V;MFaON9 zk3I2rS3~2FdVQp*vATpl!Q!v$mv6mgThl#v#4!5A_%jY^H4B*@V#x)K;g znWJYn`p6>9-&h@?-D#ZMO4~@MorI7arHzD0QM}tjjZ@#>oY9%-nuLj^lw6qLW!l%O z3n0|#mPRp~pIFzqbFM_p}|O{=Q?y6?d=Ry(+KbeN{X8i=uz| zjc;M)9b;L z&u|(1!OmLNg8uxvn?JPbJ)HjgsSUR!QBQM0IZP23%)AMw;nHg6P-ryr6`4hk*S^9b z1(-B|AqyBo?krxFzBs*Qpf6g}$YCV^;nn-7`&5#xhsnZXM2&lBBA7=dfrn1N_)6>j zIFO9)2dug7lk0BMS4e|+oJj0%JN~yvAH^6>AN6B3*Z$o4Teu4bYQ3qP#>czzxR_!_ zg35BsbtuLm5<;oP$WfpQiCzJKKFx=>7cKK~K$WwZA5Tn)DprtU4AkQp7QG_m4&r$n z13#~mr~qT-qXI_a5l>`1pBBx!DC(#Ls^hqb$VQUCKl<2xS4iv+l1o>ZI#s!Qgn z=>jObd7LS(>{yaV|1qdQ?Fd??J&?9Q{L$9$47;L9B5xb+<62p6Gi2U{L_?rN+hEt< z9C`F7tw*>61grJ8Pd&eQQQB{8y<4a(#gK{l`Mt|tWU`fOY~mj2qg z!y5{!QF`T_s*VeM0^5>9i(fmMj%E#(@dOcd6E;%ANO2b@^6Wv+m><^=R6Jy2J6mx=qHOI zoxh72!}yINSOGJ6IYz@Dgt}W&h`?ixIGuq1J7(%hi#81eX7Q>M<+nzxNkyoV7gJp$7^Jk=XItKS~U>4AD0zQ>dQF@Lfk5+i* z7#BveF=45g&gc_Im{uSn|FpPKkkl+lD|Aq~FwnqriZGaIpdIrvW{sH6@I$IR)X~a_ zu$PPDd>mb%|J;h16ACGan|(oK)p!c0AgNnS&Uunh#1$tTs=l?T=EZY|?1&D{jiMEt zq0hD@qC+mpts2G&w(6C!8yVVnR*7ngKlS@t!xW||W8odi)y0D(t`ePRKFfz8&<1r#}tbWmBu_`vBG zDC5AeFm-3iS~}0(FgPgwmS2!8JqhAp)X&_CnUhGJU71z1jGI)gmCt1jLt=tM-qnJc zj24*`KE8T4xyUpw1WI^XB&sowBx#6nWv6CrDX7K)7o2By|!t@3KAhAv=yb~FrDS&5TweLC5SFMx{c^0ZEWgfA;uN>KrN&H z^2`E>zzP+uHxmZz^`uFcmv$~|N^#TV% zwhnhw>P$PROm&wPcW^J$fK6mk#z>U84GOs%_km=hqB6S_0Nl|-MT2tsr_>{n!bMh5 zC=Ljw9sc?Cw;<9p{jEg4ymZ|iwse@zSIa;L(ql@HE_+;C;uz-Yo?9{V$`0O&({r#C zYw2(b*R^m9%mjT8FN9~v4NWC5s`PnV#Rh#L(!)?Lp;ak@pwY`*oW`nL3#EJpYDC1VmtDeNOMgdcR&cEr*T(+f%uA>y z_g1lb^@hrw^jIRbK*bSs+d$_(op^e0>oGgxiWE3Cx}R$%z+awOf(h;eE3ewjHDc$l z(g=cOvV`T-95dQG+{aPxi)|vvgLs>4QZPusHMIsEFyO@kC2f2n9gB2I2I51WFfy$3 zI^E(T5Kp?fzy0AeFCOozJKkN7A9NO^=Wqv&AnYLxhFc}99>iq=?BmehP(Jv8hfW6- zHha&1f5*@F4ELeRi){kUL=l)+4B4cYMbsLo>nnHg2ZK3wAdm4C6do%JlVVN(a7K7j zrDBG~2G}~#g={!i>w#0xJ$U+gl!}S~no+0KdF3Cjc`su~b(+ku@uRxeo@jWTS_x^x zBVcsPe`ni0z(AWP2N{3x`rj9Zy;;d!W@=lH&WBYaz#x3iYxqywKhZbbk6DOzjOY;a z{nO7gQl)TK<&@o7eI2<^MueS_=?q<{&)kZc#HvFI2KRQHsT}U3-bHCxDRX;e33mvR zCS1USOB2!1FG^3#DDx%ZGm&&fR`P}+Vj(Q`l?_7#4xh(+8hz<7=&6QR|MYpNH^{e~8`(n${vW$EhnaAs1qg|p?s@mTa(dw$yZ@l&JLuX&2gu{z@ zYwLhJ>IS-g(sE=^>(Tpn|1QG`PbeZR?jVR<2O(Ueg1qCrz!53p$(mgbQ`pnaVG8-Q zBoq}$t0HVnVu-3OBe=K3mD5DbiRmF zkVU|x1qQbKlw}v=P^PD*9qOv9$SzSUouZ4E-e0+MwH=xeA-S|<%|D!chKuCM3zqloY|>SeBXhNc~=EqP2mv3h!BF>(OJ(d1jF`N1eM65X<*YJ@-HMf0vyWAZa=C zBF)2p-u|;d&LWw3y0f_FR?M7EvV>ZYKW2jI^|Er51dvXYj7w9+#jYd|lsXEIIVLjz zHbt83siJG6cCDJl%^zJ0zhTG=gVI6jwltZzK`W79V&ufR{`Si35`wY&H4SudWGWJ8 z=Mi8;L4pIrgL~UgGx-A-h}%gEen^PJu~XAqhWa=mhc2kcijf~U0|H#_WZ|SCnt>Mz z6?%`*>?$VOZ5g=eNaKSlkP!4}a-E^M8OmY_K~c&JEk_FN25O^I#f)a35t=vt2!~E1 z9Wa(SGng?J*sYkf4LCLzuhk>xr8Aap(&-V=MVGJ=#cNt-B_o{26-8n70wBmr^^xwy zRi6;baZ$|R0*#_oXCO!a1r;J`+AhT9(t|;`zzRTB4j$JH99DCUu~zIj&-0 zaAkQp%F>GF{tm_f+G8d-3A%fv7ZnF7>3TwjA$kR!e$#AuMvgcgxOpN4f@bp&7ZFuv zyb6Wo!O1r{A4H)KjFpJ?iuxuQZZ0(+fnda*s5O-V&gCK%6QnU`KjxZ>CqiqoHE0u8 zAbAsU#7hJ`*)cOt=T{U+m;p=gh{~%8N|*lB#pT?%R8|)-lSUacoZ_6v*cEzxm^Aot zQX+!nNQ%xOgXo}gs_A@^96pfxPS2+=`h~O@6Q^N{jTga6uA*Ge#p2 z6WJRtl(0xV=Z^qRx_q|PTFWMM3%K?^i*k=`IiaE@MUmxKFGAU>#3n9!1vC!ONf(z@ zf>e!RQYu1h%7%W9p2r>JiFSDhV!_@;vss=|fEAH3gCQ4Yf8w-Lo6^w)z=;7MP8Hf? z%@h>NWK4>fm>nTjN8-W}Jko1r6p=D9w!LI+bO}S4T4HO#$|oB4!MOJ)NsT0Y?h6>1 zOgIfqCoc?B_XcHB>ysjWMG}w@Ns2hscZjfu!o)`{gH`qsJW$S#_k@u!T=1w&ge*IN zd?m?XRgeZ+l${VJ!ed|>UJ8|!3M^r(bC#XxYi4;=@6cfW;*5>D^;>+A9qMz-;2}#O z3P7r0fPP8>IY^L|Pk!~774|Jxn(9FikG+E|1^##R%m1O4AWo*J*7ew4M)Vm_91pAoPE*gNbM2NZI zH5^fhgg|FP=f_og-Z(hw*Yt zx~N6tKsykGmSpE~9OZ3QSNQGEcybq!DWncDr2`|CA}zc4Ld2Nb3A+_|$ROQ_Dhz`% z9;7bWm|wx-eXlHugG}g?ux^MH>D=B>zU_*oI;_r-2q*s%iF-GGkkM3aZ!?`4^HlX; zkyYrSB14y8jBYKciga#pY-q}an3pjm4+ig=f|{--Z}+5(`3<*_2Oek2DWS}`rXmEo z)2{0tz2x$EZx8# zB-~sjYvkf3Y|SoRl1scQrW5ZDrN&+7Lf3fwN45Z}f8&aIdQDM)oRrHDr2 zLuagGsQVv|Kgr3}#sX{*MCqb9Ma(Lya~L48A8PK2$qUcPSg+n34DKl;h}cDgrzB;y zsRJOU0CHl2!59a&Ax!|t2?l1Y&7q%w9(&IOBUPC30WCxaAteEh5IVI6joueFf5^^6 z7^jGGIB9XF#>5=z#(mAKS|U9b?CP57p>ATKj--Vd^S$NUaYL{_j+qAk>4v?pwHzfq zS`a3w*aPAt2c*Z-H!`q$`LjWxNQ{<`*1p2|a1?JXp2{e|fX;$u>Kf)SHx^WW zaOE}ZW%krPqO@&M>YnDq&ov#OQ-E!d!#TMqm{14f?T}c{zjyMv)4k0k#1-$@X-U}S z4*?O*H(QQA(Xf|UFBJOr>Z`d?iCqYnm#jNC(9ZQ}+};GXx}I~7*1gJ+n{djfw$9l; zVEdF0R_;GP^e|&N=T|UxpqLN*{1dgS?Q8k+8{hJNyL(c4&AJFVRF|4GngfJ$|Cw7cb7m0Dp|1L_u_5+%AUNi!Hsx1#jx_J@Ji|Di++?>b zC&*%fJgG~7xCDd@Pzy#qq-jTKGrVhh`h80;d8O?*ZJ<@a0=uGk&C6}a2(=QcSmYLV zURH&ZRru56s>v;*eTP|BL26kvfP*Ezy!Ts2yBZd!s%@ljmZaw)&F;|wF!0CWZC93U zL@yOl*g>A)mgEz?&8K_MVbQU)QkfLGpHnV8UrnHBSld9?AHDf)cE?bn_=L?hIm_Pc zJj1w-!UF*>H@`&^*Dl{CV#swKv$;Rtxc@7A|8Iv({Ap+>?HGxk?X#;JtanPY{OJw1 z?zGuL&pzkj;>cUR?C@aK@z->)?v{g=Ae;1OW{DAgh)e5~lw0u24*@hAW8 z*b^i|{Q^~&71ppwfayLHLgKO76fS~f4v;wsPntKvXEEg04m|i~$0_s@HeWq=J~Aczh;%Hu?0Z|mEf63e-?RuPZa z^)-Ltl8;~_F0nsQK|HpkZykT)A5T0(Atf%0PVTI_oOQ$8Jc!tV0RrRd!LB-h;|g~GjnTBN~e|gcWhwEN3%a9155YiK&ckQ`MbfyZvIQEebR9{2musXleMeu$OYq0W~m7FNMA$lc%(1p5^E(%>t9ikc1-g zh9pE0DK0+pOb$gLY%IF-d5fxB=VUb0U~eY>;vCryX4)3US8 z?vHUCUZ|&7jY;;AI)k4FPygiFGEb*$pdRQRwI>Ne8=1>_KCV##kJb@D0{%&UF_Z;>gz}5h&Ow-l z{Yp4yA;98~3kZh6PC0r%2~=BzhK9$7DS^~S1d&HjWt*h=lg^}YMwN)6 zQlLCrO_*Sh0$D|Q03Mz|5(v%&=xIq?%p@3z3m;-Zl^o=qIRMu9(^L_E0?1ldGrp+E z>AiENARTzkc{0kdtS4547Wcb(q)8X}D0{6~m!#)bWfe09!17~#+{M0?(3XK?OOQE% zdYT}23kJ6>5+{g?%7S!+BfV<;aTtL7sg)fPw|NQ)6_VUGq^5_NlbXSiW60MvPR7HO z6m~STW*2)Mz)Ho=u^}xe!Hv8y<*&$D#*vq3h$Q~TL8Ni46eov^B$rK|HRSQkdN0p^T5BfO!Lt!2ea zvbf`dh+fp=>CV*+{!K;Ilx=tcKlKH}kIlB?%r)MXrYgH^S!OY_9hN%?mV*!j`QwAQ zng=_#6|JJxG6Ga9Ia60J-GX?rZNjxK1RfngEK?MbAPyHqj0h7l5G>+_3`Fhhpw=Y8 zIvBH5nTcz3fOg)KQ(~cVZ!D~)!C~lOvXcIw8z#LVe@V+e1J%N<&j>8k8Tr^c@&I1? zCUwGa#oO9CZ3y7ZnPOFHW+WC5?e(6hJxEU~!&iyQ+UTQSI; z%Y!F+ny5P&+hDHYkVYo*Yx`U2HgF>hDvm#6bl|&2`f$_Lrf*idB$%=wU%4 zci3Zl00X9)qO`2fZMYTN2?|6m7)2MD8#90rox>+-+3S0o5q@Q6;YVt&(|9A~*WAq%44z0(Q!WEp;Mg`$5l~YCTvpQ*TbO3W7=8aW3rFT_d zb4%5gYJ99Mb^57pR_2tQ?5<}wG*$Rjr5oRmJ(yKb_MEHlZ*!$Wo@5z8ETD;N3)ykB zyFTz4?nBgEH*>J_tjEHiL~&#Cad$?_;+x7Z`^38Uvwj+0XxU~E?z{5}ddwG&1m#9v zXzIcCQ!Rtt-if0BKo!t4!a)}zk$h!|Cn8`z$}2+0Po1hpTur)a3_2JL=U8W?s*Z1a zu;6u!OueO+7ziH`crJ2fjPynM++E3GhiThfuZVw=9;`^zOO7$rkLh& zY{Aj4T4wNI(F}vE|71g&A~ImuTvS7~>hwp6x+v!KcD}$0oo{uVWCB4NO`GP}$TeIc--x_b~yNmo7FAUKPAZGNRM1&qKV z$La2dhW>VXgRBgsaE3Z#y*QH$baG%lnMK!>rEt*6jJ$(QqH|&bv+Bv7CJdqU<=DW1 zj%m_JB~hA$KKRhXWBGfM3fa=fg7hq^el$UvC*4zgw8G(8XudA5vM5vA0!_DrtoP7) zdC#qwxg6u-m=_{08i~_G#v!&Sk7vOK454IF7*PV9!cH6}0(QqNmFeoJzXr0ehLlK!KNn{;r##Mhzn}o z@z1T8k$fa~Dg&1?p57D%m4neZ-DgJ9UE||H)HFd`6!(p}(MZ)sF};jP0t#Wx7#(^P zXIex@OcduOg26vR>uCvj2!=aOr=gXPV^cb@=#JclGes;!5j)0**zm!#bMs1d(Oq|U8c7XeL({M1|=~6qrHEFLR?^ZK?1W&V4;}J zE}w- + Nossa Política de Divulgação Responsável fornece diretrizes claras para o + envio de relatórios, garantindo a confidencialidade. +--- + +import { Aside } from "@astrojs/starlight/components"; + +### Política de Divulgação Responsável + +No Xahau, acreditamos que a segurança dos nossos sistemas é extremamente importante. + +Apesar do nosso cuidado com a segurança dos nossos sistemas durante o desenvolvimento e a manutenção dos produtos, sempre há a possibilidade de alguém encontrar algo que precisamos melhorar/atualizar/alterar/corrigir/... + +Agradecemos que nos notifique o mais rápido possível caso tenha encontrado um ponto fraco em um dos nossos sistemas, para que possamos tomar medidas imediatas para proteger nossos clientes e seus dados. + +### Como Reportar + +Se você acredita ter encontrado um problema de segurança em um dos nossos sistemas, notifique-nos o mais rápido possível publicando uma **descrição de alto nível da sua descoberta e informações de contato (para que alguém possa retornar) no Github:** [**https://github.com/Xahau/xahaud/issues**](https://github.com/Xahau/xahaud/issues) + +### Regras + +Esta política de divulgação responsável não é um convite aberto para escanear ativamente nossa rede e aplicações em busca de vulnerabilidades. Nosso monitoramento contínuo provavelmente detectará sua varredura, e estas serão investigadas. + +#### Pedimos que você: + +- Não compartilhe informações sobre o problema de segurança com outras pessoas até que o problema seja resolvido, e que exclua imediatamente quaisquer dados confidenciais obtidos +- Não abuse ainda mais do problema, por exemplo, baixando mais dados do que o necessário para demonstrar a vulnerabilidade, ou visualizando, excluindo ou alterando dados de terceiros +- Forneça informações detalhadas para que possamos reproduzir, validar e resolver o problema o mais rápido possível. Inclua seus dados de teste, registros de data e hora e URL(s) do(s) sistema(s) envolvido(s) +- Deixe seus dados de contato (endereço de e-mail e/ou número de telefone) para que possamos entrar em contato com você sobre o andamento da solução. Também aceitamos relatórios anônimos. +- Não utilize ataques à segurança física, engenharia social, negação de serviço distribuída, spam ou aplicações de terceiros + +### Procedimento(s) de Divulgação Responsável + +#### Ao reportar um problema de segurança, agiremos da seguinte forma: + +- Você receberá uma confirmação de recebimento dentro de 4 dias úteis após o envio do relatório +- Você receberá uma resposta com a avaliação do problema de segurança e uma data prevista de resolução dentro de 4 dias úteis após o envio da confirmação de recebimento +- Não tomaremos medidas legais contra você em relação ao relatório se você tiver cumprido as condições estabelecidas acima +- Trataremos seu relatório de forma confidencial e não compartilharemos seus dados com terceiros sem sua permissão, a menos que isso seja necessário para cumprir uma obrigação legal + +#### Este esquema de divulgação responsável não se destina a: + +- Reclamações +- Relatórios de indisponibilidade do site +- Relatórios de phishing +- Relatórios de fraude + +Para essas reclamações ou relatórios, publique uma **descrição de alto nível do seu problema e informações de contato (para que alguém possa retornar) no Github:** [**https://github.com/Xahau/xahaud/issues**](https://github.com/Xahau/xahaud/issues) + +### Programa de recompensa por bugs + +O Xahau incentiva o reporte de problemas de segurança ou vulnerabilidades. Podemos oferecer uma recompensa adequada pela divulgação confidencial de qualquer problema de design ou implementação que possa ser usado para comprometer a confidencialidade ou integridade dos dados dos nossos usuários e que ainda não fosse do nosso conhecimento. Nós decidimos se o relatório é elegível e o valor da recompensa. + +### Exclusões + +#### Os seguintes tipos de problemas de segurança são excluídos + +- Ataques (D)DOS +- Mensagens de erro ou páginas de erro sem dados sensíveis +- Testes e dados de amostra disponíveis publicamente em nossos repositórios no Github +- Problemas comuns como avisos de cabeçalho de navegador ou configuração de DNS, identificados por varreduras de vulnerabilidade +- Relatórios de varredura de vulnerabilidade para os softwares que utilizamos publicamente +- Problemas de segurança relacionados a sistemas operacionais, navegadores ou plugins desatualizados +- Relatórios de problemas de segurança sobre os quais já fomos notificados anteriormente + +Atenção: Relatórios que não contenham nenhuma prova (como capturas de tela ou outros dados), informações detalhadas ou detalhes sobre como reproduzir qualquer resultado inesperado serão investigados, mas não serão elegíveis para nenhuma recompensa. + +Esta política é baseada nas Diretrizes de Divulgação Responsável do Centro Nacional de Segurança Cibernética e em um [exemplo de Floor Terra](https://responsibledisclosure.nl/). diff --git a/src/content/docs/br/docs/compliance/security-audit.mdx b/src/content/docs/br/docs/compliance/security-audit.mdx new file mode 100644 index 0000000..d7586b7 --- /dev/null +++ b/src/content/docs/br/docs/compliance/security-audit.mdx @@ -0,0 +1,24 @@ +--- +title: Auditorias de Segurança +--- +import { Aside } from '@astrojs/starlight/components'; + +O amendment Hooks, parte integrante da infraestrutura de contratos inteligentes do XRPL, passou por uma auditoria de segurança detalhada realizada pela FYEO. A auditoria examinou a implementação do framework Hooks, incluindo a API de Hook, funções auxiliares e o ambiente de execução. + +Sem problemas de segurança graves detectados e todos os problemas menores resolvidos, esta auditoria serve como um testemunho do nosso compromisso com a segurança e da robustez dos Hooks. + +Ao habilitar lógica de transações inteligentes diretamente na Camada 1 do XRPL, os Hooks trazem maior flexibilidade para adaptar aplicações às suas necessidades únicas, inspirando mais inovação dentro do ecossistema XRPL. + +Os desenvolvedores agora dispõem de ferramentas robustas para criar e implantar lógica personalizada, acessível em nossa testnet. + +### **Garantia de Segurança Contínua** + +A conclusão bem-sucedida da auditoria não é apenas um marco, mas um alicerce para a segurança e a sustentabilidade contínuas da rede Hooks. + +Com todas as vulnerabilidades identificadas tratadas, o amendment Hooks está pronto para impulsionar a inovação de forma segura no Xahau. + +

+ +Por um futuro mais brilhante e inovador com o Xahau! diff --git a/src/content/docs/br/docs/data-apis/index.mdx b/src/content/docs/br/docs/data-apis/index.mdx new file mode 100644 index 0000000..1afe60e --- /dev/null +++ b/src/content/docs/br/docs/data-apis/index.mdx @@ -0,0 +1,5 @@ +--- +title: "APIs de Dados" +--- + +A API de Dados principal está localizada em https://data.xahau.network/ \ No newline at end of file diff --git a/src/content/docs/br/docs/features/amendments.mdx b/src/content/docs/br/docs/features/amendments.mdx new file mode 100644 index 0000000..e229427 --- /dev/null +++ b/src/content/docs/br/docs/features/amendments.mdx @@ -0,0 +1,184 @@ +--- +title: Amendments +--- +Os amendments representam novos recursos ou outras mudanças no processamento de transações. + +O sistema de amendments usa o processo de consenso para aprovar quaisquer mudanças que afetem o processamento de transações no Xahau. Mudanças totalmente funcionais no processamento de transações são introduzidas como amendments; os validadores então votam nessas mudanças. Se um amendment receber mais de 80% de suporte por cinco dias, ele é aprovado e a mudança se aplica permanentemente a todas as versões subsequentes do ledger. Desabilitar um amendment aprovado requer um novo amendment para isso. + +**Nota:** Correções de bugs que alteram processos de transação também requerem amendments. + +### Processo de Amendment + +O tópico Contribuindo com Código para o Xahau percorre o fluxo de trabalho para desenvolver um amendment desde uma ideia até a ativação no Xahau. + +Após o código de um amendment ser incorporado a uma versão do software, o processo para habilitá-lo ocorre dentro da rede Xahau, que verifica o status dos amendments a cada ledger _flag_ (geralmente com cerca de 15 minutos de intervalo). + +Cada 256º ledger é chamado de ledger **flag**. O ledger flag não possui conteúdo especial, mas o processo de amendment ocorre em torno dele. + +1. **Flag Ledger -1:** Quando os validadores `xahaud` enviam mensagens de validação, eles também submetem seus votos de amendment. +2. **Flag Ledger:** Os servidores interpretam os votos dos validadores confiáveis. +3. **Flag Ledger +1:** Os servidores inserem uma pseudo-transação `EnableAmendment` e sinalizam com base no que acreditam ter acontecido: + + * O sinalizador `tfGotMajority` significa que o amendment tem mais de 80% de suporte. + * O sinalizador `tfLostMajority` significa que o suporte ao amendment diminuiu para 80% ou menos. + * Nenhum sinalizador significa que o amendment está habilitado. + + **Nota:** É possível que um amendment perca 80% de suporte no mesmo ledger em que atinge o período necessário de cinco dias para ser habilitado. Nesses casos, uma pseudo-transação `EnableAmendment` é adicionada para ambos os cenários, mas o amendment é habilitado de qualquer forma. +4. **Flag Ledger +2:** Os amendments habilitados se aplicam às transações a partir deste ledger em diante. + +### Votação de Amendments + +Cada versão do `xahaud` é compilada com uma lista de amendments conhecidos e o código para implementá-los. Os operadores de validadores `xahaud` configuram seus servidores para votar em cada amendment e podem alterar isso a qualquer momento. Se o operador não escolher um voto, o servidor usa um voto padrão definido pelo código-fonte. + +**Nota:** O voto padrão pode mudar entre versões do software. \[Atualizado em: rippled 1.8.1]\[] + +Os amendments devem manter cinco dias de suporte de mais de 80% dos validadores confiáveis para serem habilitados. Se o suporte cair abaixo de 80%, o amendment é temporariamente rejeitado e o período de duas semanas é reiniciado. Os amendments podem ganhar e perder a maioria qualquer número de vezes antes de se tornarem permanentemente habilitados. + +Amendments cujo código-fonte foi removido sem serem habilitados são considerados **vetados** pela rede. + +### Servidores Bloqueados por Amendment + +O bloqueio por amendment é um recurso de segurança para proteger a precisão dos dados do Xahau. Quando um amendment é habilitado, os servidores que executam versões anteriores do `xahaud` sem o código-fonte do amendment não entendem mais as regras da rede. Em vez de adivinhar e interpretar incorretamente os dados do ledger, esses servidores ficam **bloqueados por amendment** e não podem: + +* Determinar a validade de um ledger. +* Enviar ou processar transações. +* Participar do processo de consenso. +* Votar em futuros amendments. + +A configuração de votação de um servidor `xahaud` não tem impacto no bloqueio por amendment. Um servidor `xahaud` sempre segue os amendments habilitados pelo restante da rede, portanto, os bloqueios são baseados exclusivamente em ter o código para entender as mudanças de regras. Isso significa que você também pode ser bloqueado por amendment se conectar seu servidor a uma rede paralela com diferentes amendments habilitados. Por exemplo, a Testnet do Xahau geralmente tem amendments experimentais habilitados. Se você estiver usando a versão de produção mais recente, seu servidor provavelmente não terá o código para esses amendments experimentais. + +Você pode desbloquear servidores bloqueados por amendment atualizando para a versão mais recente do `xahaud`. + +### Aposentadoria de Amendments + +Quando os amendments são habilitados, o código-fonte para comportamentos anteriores ao amendment permanece no `xahaud`. Embora haja casos de uso para manter o código antigo, como reconstruir resultados de ledger para verificação, rastrear amendments e código legado adiciona complexidade ao longo do tempo. + +O [XRP Ledger Standard 11d](https://github.com/XRPLF/XRPL-Standards/discussions/19) define um processo para aposentar amendments antigos e o código pré-amendment associado. Após um amendment ter sido habilitado na Mainnet por dois anos, ele pode ser aposentado. Aposentar um amendment o torna parte do protocolo central de forma incondicional; ele não é mais rastreado ou tratado como um amendment, e todo o código pré-amendment é removido. + +### Amendments Conhecidos + +Os seguintes amendments foram implementados ou estão em processo de habilitação no Xahau: + +#### Amendments de Funcionalidade + +##### XahauGenesis + +Permite que a conta gênesis emita XAH e o distribua via [transações GenesisMint](/docs/protocol-reference/transactions/transaction-types/genesismint-emitted-txn). + +##### MultiSign + +Habilita a funcionalidade de múltiplas assinaturas, permitindo que as contas exijam várias assinaturas para transações. Este amendment introduz [transações SignerListSet](/docs/protocol-reference/transactions/transaction-types/signerlistset) e [objetos de ledger SignerList](/docs/protocol-reference/ledger-data/ledger-objects-types/signers-list) para suportar múltiplas assinaturas. + +##### DepositAuth + +Habilita a funcionalidade de autorização de depósito, permitindo que as contas exijam pré-autorização antes de receber pagamentos. Este amendment introduz [transações DepositPreauth](/docs/protocol-reference/transactions/transaction-types/depositpreauth) e [objetos de ledger DepositPreauth](/docs/protocol-reference/ledger-data/ledger-objects-types/deposit-pre-auth) para gerenciar pré-autorizações. + +##### Hooks + +Amendment principal que habilita a funcionalidade de contratos inteligentes Hook no Xahau. _(Adicionado pelo [amendment Hooks][].)_ + +##### HooksUpdate1 + +Atualizações e melhorias no sistema de Hooks. + +##### Remit + +Implementa o [XLS-55](https://github.com/XRPLF/XRPL-Standards/discussions/156). Um novo tipo de transação de pagamento push simples e poderoso do tipo "o que você vê é o que você obtém". Habilita [transações Remit](/docs/protocol-reference/transactions/transaction-types/remit) que permitem pagar múltiplas moedas e URITokens na mesma transação para o mesmo destino. A transação paga automaticamente para criar trustlines ausentes, paga automaticamente as reservas em tokens transferidos e paga automaticamente para criar a conta de destino caso ela não exista. Você pode cunhar um recibo ou URIToken bônus inline dentro da transação. Opcionalmente, informe um Hook de terceiros sobre a transação. Sem pagamentos parciais e sem roteamento. + +##### ZeroB2M + +Desabilita o caminho de queima para cunhagem de XRP para XAH. O comportamento normal da transação Import permanece, mas o XRP queimado não é creditado. O B2M ainda está disponível para sincronização de chaves ou para ativar uma conta, mas não pode ser usado para cunhar novos ativos. + +##### Remarks + +O amendment Remarks permite que pares chave-valor (semelhante ao estado de hook) sejam armazenados pelos proprietários de objetos nesses objetos. Isso é como virar um documento e escrever uma nota à mão nele. Os Remarks podem ser qualquer coisa e significar coisas diferentes para partes diferentes. Os Remarks também podem ser definidos como imutáveis. Os Remarks seguem um objeto ao longo das mudanças de propriedade e podem ser usados para alcançar casos de uso inovadores, como NFTs dinâmicos e simplificar algumas operações de estado de hook que de outra forma seriam muito complicadas. Habilita [transações SetRemarks](/docs/protocol-reference/transactions/transaction-types/setremarks). + +##### Touch + +Este amendment garante que todas as contas envolvidas em uma transação (todos os stakeholders transacionais) sejam forçadas a aparecer em seus metadados, incrementando um "contador de toque" mesmo que nada mais na conta tenha sido alterado. O nome é uma referência ao utilitário de arquivo unix `touch`. Isso proporciona melhor consistência de auditoria e facilidade de programação de ferramentas automatizadas. + +##### HookCanEmit + +Este amendment adiciona um novo campo aos objetos HookSet: `HookCanEmit` é sintaticamente idêntico ao campo `HookOn`, exceto que controla quais tipos de transação o Hook tem permissão para emitir, em vez de quais tipos de transação acionam o Hook. Observe que ele usa a mesma semântica active-low que `HookOn`, com `SetHook` sendo active-high. No entanto, se o campo estiver ausente, presume-se que o Hook pode emitir qualquer transação, incluindo `SetHook`. Adiciona o campo `HookCanEmit` aos objetos [HookDefinition](/docs/protocol-reference/ledger-data/ledger-objects-types/hook-definition). + +##### Clawback + +Habilita [transações Clawback](/docs/protocol-reference/transactions/transaction-types/clawback) que permitem aos emissores revogar tokens que foram previamente emitidos por sua conta. Este é um recurso portado do XRPL. _(Introduzido em 2025.7.9-release+1951)_ + +##### DeepFreeze + +Habilita a funcionalidade de congelamento profundo para trustlines e ativos. Este é um recurso portado do XRPL. _(Introduzido em 2025.7.9-release+1951)_ + +##### IOUIssuerWeakTSH + +Torna os emissores de IOU stakeholders transacionais fracos (TSH) em certos tipos de transação. Garante que os Emissores de Moeda tenham seus hooks executados em transações de terceiros que tocam ou mencionam sua moeda, se optarem pela execução fraca. Consulte [Fraco e Forte](/docs/hooks/concepts/weak-and-strong) para detalhes. _(Introduzido em 2025.7.9-release+1951)_ + +##### Cron + +Habilita a execução agendada de Hook via [transações CronSet](/docs/protocol-reference/transactions/transaction-types/cronset) e [objetos de ledger Cron](/docs/protocol-reference/ledger-data/ledger-objects-types/cron). Este recurso permite que os Hooks agendem uma série de auto-invocações futuras (semelhante a um cronjob em sistemas Linux), o que pode auxiliar os desenvolvedores de Hook a escrever estruturas de governança complexas, jogos e mais. O número máximo de repetições é 256, no entanto, emitir uma transação `CronSet` adicional pode estender esse limite quando o número de repetições ultrapassar um limite mínimo desejado. _(Introduzido em 2025.10.27-release+2405)_ + +##### ExtendedHookState + +Estende as capacidades de gerenciamento de estado de Hook, incluindo o campo `HookStateScale` para objetos [AccountRoot](/docs/protocol-reference/ledger-data/ledger-objects-types/accountroot) para controlar quando as entradas de estado de Hook ficam obsoletas. Este recurso expande a quantidade de dados que os Hooks podem armazenar em seu Hook State (sistema chave-valor para Hooks) para permitir que os Hooks tenham armazenamento de dados mais rico quando necessário. A escala (até 16) afeta tanto o tamanho máximo do valor que você pode armazenar em um único estado de hook, quanto o número de unidades de reserva que esse par k-v consome. Uma escala de 1 (padrão) significa que você paga 1 reserva por até 256 bytes armazenados por Hook State. Uma escala de 4 significa que você paga 4 unidades de reserva por até 1024 bytes por Hook State. É importante notar que você paga essa taxa (a taxa de escala) mesmo que todos os seus Hook States contenham apenas um único byte. É possível aumentar a escala após seu Hook já ter armazenado estado, mas não diminuí-la. Diminuir a escala requer que todo o HookState seja primeiro excluído. _(Introduzido em 2025.10.27-release+2405)_ + +#### Amendments de Correção de Bugs + +##### fixXahauV1 + +Impõe um limite de 256 namespaces por conta. Várias correções de bugs com a lógica do URIToken. Garante que STAmounts padrão (0) sejam registrados nos metadados. Garante que OfferID possa ser usado em vez de OfferSequence ao cancelar uma oferta. Corrige um bug onde certos hooks não podem ser excluídos. Corrige um bug onde o quórum necessário para um `ttIMPORT` é acidentalmente muito alto. Permite que contas apareçam mais de uma vez em uma transação GenesisMint. Altera o Emissor de um URIToken de TSH forte para fraco quando um URIToken está sendo queimado. Garante que os TSHes em escrows criados por transações emitidas sejam acionados corretamente. Adiciona taxa de tamanho de parâmetros de hook a todas as transações (1 drop por byte). _(Introduzido em 2024.9.11-release+985)_ + +##### fixXahauV2 + +Limpa a lógica TSH e remove tabela redundante antiga. Adiciona sinalizadores informativos a cada membro de `sfHookExecutions`, descrevendo execução fraca, forte etc. Adiciona `sfEmitNonce` a cada membro de `sfHookEmissions`, para melhor desambiguação de transações emitidas. Verificações de sanidade adicionais em transações emitidas para garantir que sejam colocadas no ledger correto. + +##### fixXahauV3 + +Correções adicionais para problemas de implementação do protocolo Xahau. Este amendment garante consistência e resultados sensatos para vários casos extremos. Este amendment está configurado com voto padrão: _sim_. Se os validadores desejarem votar contra este amendment, devem alterar manualmente seu voto para não. _(Introduzido em 2025.2.6-release+1299)_ + +##### fixNSDelete + +Corrige o comportamento da exclusão de namespace de Hook State para garantir a consistência do ledger. Introduz um novo código tes: `tesPARTIAL`. `tesPARTIAL` é retornado se a transação foi bem-sucedida, mas deve ser reenviada pelo usuário com um novo número de sequência para concluir o trabalho amortizado até que `tesSUCCESS` seja retornado. + +##### fix240819 + +Amendment de correção de bug de 19 de agosto de 2024. + +##### fixPageCap + +Corrige problemas relacionados aos limites de capacidade de página. + +##### fix240911 + +Amendment de correção de bug de 11 de setembro de 2024. + +##### fixFloatDivide + +Corrige problemas com operações de divisão de ponto flutuante nos Hooks. Este amendment garante o tratamento adequado da divisão por zero e casos extremos na função `float_divide`. Altera o comportamento da API de hook `float_divide` para corrigir um pequeno erro. Este amendment está configurado com voto padrão: _sim_. Consulte [float_divide](/docs/hooks/functions/float/float_divide) para detalhes. _(Introduzido em 2024.11.18-release+1141)_ + +##### fixReduceImport + +Corrige problemas relacionados ao processamento da transação Import. Este amendment garante consistência e resultados sensatos para vários casos extremos. Este amendment está configurado com voto padrão: _sim_. Se os validadores desejarem votar contra este amendment, devem alterar manualmente seu voto para não. _(Introduzido em 2025.2.6-release+1299)_ + +##### fix20250131 + +Amendment de correção de bug de 31 de janeiro de 2025. Este amendment garante consistência e resultados sensatos para vários casos extremos. Este amendment está configurado com voto padrão: _sim_. Se os validadores desejarem votar contra este amendment, devem alterar manualmente seu voto para não. _(Introduzido em 2025.2.6-release+1299)_ + +##### fixRewardClaimFlags + +Corrige problemas com os sinalizadores da transação de reivindicação de recompensa. + +##### fixProvisionalDoubleThreading + +Corrige problemas com o encadeamento duplo provisório no processamento de transações. Garante que o PreviousTxnID correto e os metadados de transação sejam mantidos em cenários de encadeamento duplo. _(Introduzido em 2025.7.9-release+1951)_ + +##### fixInvalidTxFlags + +Corrige um bug que atualmente permite que sinalizadores inválidos sejam fornecidos a algumas transações. Embora esses sinalizadores inválidos atualmente não façam nada, eles deveriam produzir um erro de malformação. Após a aplicação desta correção, sinalizadores inválidos produzirão um erro de malformação conforme esperado. _(Introduzido em 2025.10.27-release+2405)_ + +##### fixCronStacking + +Corrige problemas com o comportamento de empilhamento de transações Cron. + +### Status dos Amendments + +Para o status mais atualizado dos amendments (habilitados, em votação ou vetados), verifique o [repositório xahaud](https://github.com/Xahau/xahaud) ou consulte um servidor `xahaud` em execução usando o comando `feature`. diff --git a/src/content/docs/br/docs/features/balance-adjustments.mdx b/src/content/docs/br/docs/features/balance-adjustments.mdx new file mode 100644 index 0000000..b719675 --- /dev/null +++ b/src/content/docs/br/docs/features/balance-adjustments.mdx @@ -0,0 +1,70 @@ +--- +title: Ajustes de Saldo +description: Como reivindicar um Ajuste de Saldo no Xahau +--- +### Adesão + Reivindicação + +Aderir aos Ajustes de Saldo é a mesma transação que reivindicar um ajuste. Você deve fazer isso primeiro para iniciar a capacidade de reivindicar mais tarde. + +```json +{ + "Account": "", + "TransactionType": "ClaimReward", + "Issuer": "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh", + "NetworkID": 21337 +} +``` + +### Cancelar Adesão + +Para cancelar a adesão aos Ajustes de Saldo, omita o campo Issuer e defina Flags como 1. Fazer isso excluirá suas estatísticas de saldo médio. Elas não serão restauradas. Se você aderir novamente, serão redefinidas para uma posição inicial. + +```json +{ + "Account": "", + "TransactionType": "ClaimReward", + "NetworkID": 21337, + "Flags": 1 +} +``` + +### Detalhes Técnicos + +Os Ajustes de Saldo são implementados como uma combinação de duas partes de código: + +1. Amendment BalanceRewards (código nativo) +2. Hook de Recompensa da Conta Gênesis (código de hook). + +O BalanceRewards coleta estatísticas de saldo médio sobre as contas nas quais está ativado. Essas estatísticas são então passadas para um Hook alvo quando o usuário deseja reivindicar. + +Todas as interações com este amendment são feitas via a transação ClaimReward: + +```json +{ + "Account": "", + "TransactionType": "ClaimReward", + "Issuer": "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh", + "NetworkID": 21337 +} +``` + +Quando uma transação ClaimReward é submetida com sucesso com o código de erro **tesSUCCESS**, as estatísticas de saldo médio da conta são redefinidas. A única outra coisa que o amendment faz é invocar os Hooks na conta do Emissor especificado. + +O campo _Issuer_ é a conta responsável por cumprir a reivindicação. Dependendo do que está instalado na conta do Emissor, várias coisas podem acontecer: + +* Se nenhum Hook estiver instalado na conta do Emissor, nada é feito e as estatísticas do BalanceRewards são simplesmente redefinidas. +* Se um Hook estiver instalado na conta do Emissor e o Hook realizar um rollback, a transação falha e as estatísticas _não_ são redefinidas. +* Se um Hook estiver instalado na conta do Emissor e o Hook realizar um accept, a transação é bem-sucedida e as estatísticas são redefinidas. Nesse caso, o Hook também deve emitir uma transação de volta para a conta do usuário contendo sua recompensa. + +Na prática, no Xahau, o Emissor provavelmente sempre será a conta gênesis **rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh**. + +A menos que: + +* A Governança da Rede resulte em uma conta diferente sendo usada para os AjustesDeSaldo. +* Uma parte não relacionada à Governança execute seu próprio sorteio de BalanceRewards com o qual o usuário deseja participar. Observe que reivindicações bem-sucedidas resultam na redefinição das estatísticas de saldo médio, portanto, apenas um tipo de recompensa pode ser reivindicado por redefinição. + +As estatísticas de saldo médio existem como uma coleção de três novos campos no objeto AccountRoot. São eles: + +
CampoTipoExplicação
sfRewardAccumulatorUINT64A área sob o gráfico de saldo-tempo da sua conta desde a última transação ClaimReward.
sfRewardLgrFirstUINT32O número do ledger da última transação ClaimReward.
sfRewardLgrLastUINT32O número de sequência do ledger da última transação de entrada ou saída da sua conta.
sfRewardTimeUINT32O tempo do ledger em que a última recompensa foi reivindicada.
+ + diff --git a/src/content/docs/br/docs/features/burn-2-mint.mdx b/src/content/docs/br/docs/features/burn-2-mint.mdx new file mode 100644 index 0000000..35ece09 --- /dev/null +++ b/src/content/docs/br/docs/features/burn-2-mint.mdx @@ -0,0 +1,291 @@ +--- +title: Burn 2 Mint (B2M) +description: >- + O Burn2Mint é um primitivo inter-chain de baixo nível destinado a usuários + empresariais para fornecer sua própria liquidez conforme necessário. +--- +import { Aside, Tabs, TabItem } from '@astrojs/starlight/components'; + + + +## Manual Técnico do Burn2Mint (Testnet do Xahau) + + + +O Burn2Mint é um primitivo inter-chain de baixo nível destinado a usuários empresariais para fornecer sua própria liquidez conforme necessário. Executar seus próprios nós e realizar esta operação você mesmo em seus nós significa que você e somente você arca com a responsabilidade pelo resultado do procedimento. + +A geração e coleta de XPOPs depende fundamentalmente da coleta de mensagens de validação na rede overlay, que são efêmeras por natureza. Se seus nós não estiverem conectados de forma confiável, ou se seu hardware, conexão de rede ou sistema operacional falhar no momento errado, o XPOP de uma Transação de Queima pode não ser gerado ou pode não ser gerado corretamente. Isso pode levar à perda de fundos, pois o XPOP da Transação de Queima não foi capturado a tempo, e é possível que as mensagens de validação sejam perdidas para sempre, tornando uma Transação de Cunhagem impossível apesar de uma Transação de Queima bem-sucedida. + +Se você não estiver confortável com esses riscos técnicos, não entender o que está fazendo, ou não for um usuário empresarial, por favor, obtenha sua liquidez por meio de outras alternativas mais amigáveis. + +### Configuração + +Para realizar o B2M, _dois_ nós do protocolo XRPL devem ser operados pelo usuário: + +1. **Obter xPOP da queima** + + + +Execute isso (por exemplo, usando Docker Compose; veja os Docs do repositório)\ +[**https://github.com/Xahau/Validation-Ledger-Tx-Store-to-xPOP**](https://github.com/Xahau/Validation-Ledger-Tx-Store-to-xPOP) + +* O serviço ouve mensagens de validação do XRPL, ledgers fechados e transações. +* Ele armazena esses dados em um sistema de arquivos organizado. +* É essencial para gerar xPOPs, pois as mensagens de validação do XRPL são efêmeras; sem armazená-las, uma queima de transação não pode ser convertida em uma cunhagem. +* **Como funciona**: + * Um observador conecta-se a vários nós XRPL e escuta dados específicos. + * Os dados capturados são então salvos, organizados e usados para gerar xPOPs. + +Simplesmente busque o xPOP agora em:\ +`http[s]://{seu-host}:{sua-porta}/xpop/{tx-hash}` + +Você pode facilmente buscar/criar xPOPs de um nó usando o repositório acima com este pacote NPM: + +[**https://www.npmjs.com/package/xpop**](https://www.npmjs.com/package/xpop) + + + +**Nó de Queima**, composto por: + +* Uma instância modificada do Rippled (modificada para registrar XPOPs) +* Binário universal para Linux aqui: [https://tvntezq.dlvr.cloud/rippled_with_xpop](https://tvntezq.dlvr.cloud/rippled_with_xpop) +* [https://github.com/RichardAH/rippled/tree/proof-of-burn](https://github.com/RichardAH/rippled/tree/proof-of-burn) +* Executando com um rippled.cfg que tem: + * uma stanza **\[xpop_dir]** especificando um diretório de saída para os XPOPs gerados. + * uma stanza **\[network_id]** especificando network_id: 1 + * (em produção, seria a rede 0) + * um `validators.txt` contendo:\\ + + ``` + [validator_list_sites] + https://vl.altnet.rippletest.net + [validator_list_keys] + ED264807102805220DA0F312E71FC2C69E1552C9C5790F6C25E3729DEB573D5860 + ``` + + + +2. **Cunhagem** + +* Neste cenário de teste, você se conectará diretamente ao Xahau. Você não precisa executar seu próprio nó. No cenário de produção, você precisará executar um nó de Cunhagem, que é apenas um nó padrão para a rede de destino. Isso ocorre porque os nós públicos provavelmente optarão por não aceitar transações Import devido a riscos legais. + * Conecte-se a **wss://xahau-test.net** + * Ou baixe/execute: [**https://github.com/Xahau/Xahau-Testnet-Docker**](https://github.com/Xahau/Xahau-Testnet-Docker) + +## Exemplo (nodejs) + +Este exemplo cria uma conta na testnet, queima 10 XRP e então importa isso na Testnet do Xahau, usando o xPOP obtido com as ferramentas mencionadas acima. + +```js +import { derive, utils, signAndSubmit } from 'xrpl-accountlib' +import { TxData } from 'xrpl-txdata' +import { XrplClient } from 'xrpl-client' +import { xpop, setEndpoints as xpopEndpoints } from 'xpop' +import fetch from 'node-fetch' + +// O acima requer: +// npm install xrpl-accountlib xrpl-txdata xrpl-client xpop node-fetch + +console.log('Obtendo conta na Testnet do XRPL (faucet)') +const faucet = await (await fetch('https://faucet.altnet.rippletest.net/accounts', { method: 'POST' })).json() +console.log(' -->', faucet.account.address) +const account = derive.familySeed(faucet.account.secret) + +xpopEndpoints((await (await fetch('https://xrpl.ws-stats.com/xpop/list?json=true')).json()).bestguess) + +const nodes = { + testnet: [ + new XrplClient('wss://s.altnet.rippletest.net:51233'), + new XrplClient('wss://testnet.xrpl-labs.com'), + ], + xahau: [ + new XrplClient('wss://xahau-test.net'), + ] +} + +console.log('Aguardando as conexões de rede ficarem prontas') +await Promise.all(Object.keys(nodes).map(k => Promise.race(nodes[k].map(n => n.ready())))) + +console.log('Aguardando o financiamento da conta pelo faucet e obtendo valores da rede...') +await new Promise(resolve => setTimeout(resolve, 4000)) // Aguarda o fechamento do ledger + +const [ + testnetParams, + xahauParams, +] = await Promise.all([ + Promise.race(nodes.testnet.map(n => utils.accountAndLedgerSequence(n, account))), + Promise.race(nodes.xahau.map(n => utils.accountAndLedgerSequence(n, account))), +]) + +const testnetTx = { + ...testnetParams.txValues, + TransactionType: 'AccountSet', + Fee: String(10_000_000), + OperationLimit: xahauParams.txValues.NetworkID, + NetworkID: undefined, // A Testnet tem NetworkID < 1024, então nenhum deve ser fornecido +} + +console.log('Enviando queima...', testnetTx) +const testnetSubmitted = await Promise.race(nodes.testnet.map(n => signAndSubmit(testnetTx, n, account))) +console.log('Queima enviada para a testnet') +console.log(' -->', 'https://testnet.xrpl.org/transactions/' + testnetSubmitted.tx_id) + +console.log('Obtendo dados da transação de queima...') + +const txdata = new TxData(nodes.testnet.map(n => n.getState().server.uri), { + AllowNoFullHistory: true, + EndpointTimeoutMs: 2_000, + OverallTimeoutMs: 10_000, +}) + +const appliedtx = await txdata.getOne(testnetSubmitted.tx_id) +console.log(' -->', 'Queima validada no ledger', appliedtx?.result?.ledger_index) + +console.log('Aguardando ledger fechado antes de buscar o xPOP...') +await new Promise(resolve => setTimeout(resolve, 4000)) // Aguarda o fechamento do ledger + +console.log('Buscando xPOP...') + +const Blob = await xpop(testnetSubmitted.tx_id, appliedtx?.result?.ledger_index, 1) + +console.log(' -->', 'xPOP obtido, comprimento hex:', Blob.length) + +const hooksTx = { + ...xahauParams.txValues, + TransactionType: 'Import', + Fee: '0', + Blob, +} + +console.log('Enviando para cunhagem do xPOP...') + +const b2mSubmitted = await Promise.race(nodes.xahau.map(n => signAndSubmit(hooksTx, n, account))) + +console.log(' -->', 'B2M enviado! TX na Testnet do Xahau:') +console.log(' -->', 'https://test.xahauexplorer.com/explorer/' + b2mSubmitted?.tx_id) +console.log(' -->', b2mSubmitted.response.engine_result, b2mSubmitted.response.engine_result_message) + +// Fechando conexões +Object.keys(nodes).map(k => nodes[k].map(n => n.close())) +``` +[Fonte](https://gist.github.com/WietseWind/cd8a7a8c88f218fe7b768f59a665685d) + +## Resumo Técnico do Procedimento B2M + +#### Novo Tipo de Transação: `Import` + +A Testnet do Xahau (_network_id=21338_) introduz um novo tipo de transação chamado _**Import**_, que aceita um XPOP da cadeia testnet do Ripple (_network_id=1_) e fornece uma transferência de valor unidirecional "queima para cunhagem" e sincronização de chaves/contas. + +### Transação de Queima + +Uma _**Transação de Queima**_ é uma transação que queima XRP em uma cadeia XRPL de origem, que seria usada como prova (XPOP) para cunhar em uma cadeia XRPL de destino. + +Os seguintes tipos de transação são suportados: + +* AccountSet +* SetRegularKey +* SignerListSet. + + + +Observe que outros tipos de transação não são atualmente suportados e não podem ser usados para cunhar na Testnet do Xahau. (No entanto, isso pode mudar). + +Todos os três tipos de transação podem ser usados para cunhagem. Isso significa que a _**Taxa**_ queimada pela Transação de Queima é subsequentemente cunhada na Testnet do Xahau após um `Import` bem-sucedido. + +Se `SetRegularKey` ou `SignerListSet` for usado, a sincronização de chaves ocorre de acordo com as regras padrão do tipo de transação. Se `AccountSet` for usado, nenhuma sincronização de chaves ocorre na cadeia XRPL de destino (Testnet do Xahau). + +Um campo chamado _**OperationLimit**_ deve estar presente na Transação de Queima para ser o ID de rede da cadeia de destino. Este campo é para prevenir ataques de replay em outras cadeias integradas ao B2M. + +A Transação de Queima pode ser usada para Cunhagem se tiver um código de transação **tesSUCCESS** ou _qualquer_ um dos códigos de transação **tec**. Isso significa que _se_ a taxa foi queimada, a transação pode ser usada para cunhagem. No entanto, a sincronização de chaves _apenas_ ocorre quando o resultado da Transação de Queima foi tesSUCCESS. + +Exemplo de Transação de Queima: + +```json +{ + "TransactionType": "AccountSet", + "Fee": 10000000, + "OperationLimit": 21338 +} +``` + +### Coleta de XPOP + +Antes de enviar a Transação de Queima, certifique-se de que seu Nó de Queima esteja sincronizado com a cadeia testnet (ID de rede: `1`). + +Após verificar o estado do seu Nó de Queima, envie a Transação de Queima assinada para o Nó de Queima. + +O Nó de Queima observa ledgers fechados em busca de transações contendo o campo **OperationLimit** e usa as mensagens de validação coletadas para gerar um XPOP (Prova de Queima). Estes são gravados em um arquivo no diretório especificado na stanza **\[xpop_dir]** no `rippled.cfg` do Nó de Queima. + +Aguarde o fechamento do ledger e, em seguida, navegue pelo xpop_dir em busca do XPOP da Transação de Queima de acordo com seu TXID. O arquivo contém um documento JSON, que é o XPOP que você estará retransmitindo para a cadeia XRPL de destino (HooksV3). + +Pegue o conteúdo bruto deste arquivo e codifique-o como HEX. Isso se tornará o conteúdo do campo \*_Blob_ na transação `Import`. + +### Transação de Cunhagem + +Seu codec binário estará sem os campos necessários para construir a transação `Import` (Cunhagem). Se você estiver usando ripple-binary-codec, pode atualizar seu arquivo `definitions.json` da seguinte forma: + +1. Mude o diretório para `node_modules` +2. Execute `find . | grep 'dist/enums/definitions.json'` para localizar o arquivo relevante a ser atualizado +3. Conecte-se a **wss://hooks-testnet-v3.xrpl-labs.com** +4. Solicitação: `{"command":"server_definitions"}` +5. Despeje o conteúdo da chave `"result"` no `definitions.json` do passo 2. + +O tipo de transação `Import` aceita apenas um campo não-comum: _**Blob**_. Este deve conter o XPOP codificado em HEX da fase de Coleta de XPOP. + +* Você pode fazer isso com `cat xpopjsonfile | xxd -p | tr -d '\n'` + +O campo `Account` e o campo `SigningPubKey` (ou array Signers) devem corresponder exatamente entre a Transação de Queima e a Transação de Cunhagem. Os usuários só podem cunhar para a mesma conta da qual queimaram. + +Se o campo `Account` especificar uma conta que ainda não existe na Testnet do Xahau, ela será criada. Nesse caso, use 0 para o campo `Sequence` na Transação de Cunhagem. Se a conta já existir na Testnet do Xahau, use o próximo número de sequência disponível na conta na Testnet do Xahau. + +Exemplo de Import: + +```json +{ + "Account": "", + "TransactionType": "Import", + "Blob": "", + "Sequence": 0 +} +``` + +IMPORTANTE: **A Transação de Cunhagem deve ser assinada exatamente da mesma forma e pela mesma conta que a Transação de Queima!** + +Codifique e assine a transação adequadamente, produzindo um blob de transação assinada (hex). + +Se você não estiver executando seu próprio nó de Cunhagem: + +* Conecte-se a **wss://xahau-testn.et** +* Envie a transação para o nó: + +```json +{ + "command": "submit", + "tx_blob": "" +} +``` + +Ou, se estiver executando seu próprio nó de Cunhagem: + +* Certifique-se de que o Nó de Cunhagem esteja em execução e sincronizado com o ID de rede 21338. +* Use a chamada RPC `submit` para enviar a Transação de Cunhagem. + * Você pode fazer isso pela linha de comando usando `./hooksv3d submit ` + +### Considerações + +Se a Conta for criada na Testnet do Xahau, mas o keying para a conta não estiver claro a partir do contexto da Transação de Queima, a Conta será criada em modo blackholed. Ela pode ser re-keyada posteriormente usando qualquer um dos tipos de transação de keying. + +Se a Transação de Queima for `SignerListSet` ou `SetRegularKey`, desde que tenha tido um resultado de transação tesSUCCESS na cadeia XRPL de origem (testnet), essa mesma operação de keying agora é aplicada a essa mesma conta na cadeia XRPL de destino (Testnet do Xahau). + +Durante os testes, contas na Testnet do Xahau _podem_ ser excluídas; no entanto, na cadeia de produção com Hooks habilitados, elas não poderão ser excluídas. + +Contas na Testnet do Xahau têm um campo opcional _**ImportSequence**_ no AccountRoot. Se o `Import` já foi usado nessa conta na Testnet do Xahau, este campo estará presente e será preenchido com o número de sequência da Transação de Queima importada mais recentemente. Isso é para prevenir ataques de replay, mas também significa que você nunca deve enviar seus Burn2Mints fora de sequência; caso contrário, as transações ignoradas nunca serão aceitas para Cunhagem. diff --git a/src/content/docs/br/docs/features/developer-tooling/client-libraries.mdx b/src/content/docs/br/docs/features/developer-tooling/client-libraries.mdx new file mode 100644 index 0000000..8ae564e --- /dev/null +++ b/src/content/docs/br/docs/features/developer-tooling/client-libraries.mdx @@ -0,0 +1,10 @@ +--- +title: Bibliotecas de Cliente +--- +Essas bibliotecas de cliente simplificam parte do trabalho comum de acesso e processamento de dados do XAH Ledger e os apresentam em um formato que corresponde às convenções nativas de suas respectivas linguagens de programação. + +Para outras linguagens de programação, você pode acessar o XAH Ledger por meio das APIs HTTP. + +
LinguagemNome da BibliotecaPrimeiros PassosProtocoloCódigo Fonte
Pythonxahau-pyPrimeiros PassosXAH / XRPRepositório
JavaScript / TypeScriptxahau.jsPrimeiros PassosXAH / XRPRepositório
JavaScript / TypeScriptxrpl-accountlibPrimeiros Passos
Exemplo		XAH / XRPRepositório
+ +**Dica:** Para adicionar uma biblioteca de cliente não listada aqui, por favor sugira alterações nesta página! diff --git a/src/content/docs/br/docs/features/developer-tooling/curated-tooling.mdx b/src/content/docs/br/docs/features/developer-tooling/curated-tooling.mdx new file mode 100644 index 0000000..8258114 --- /dev/null +++ b/src/content/docs/br/docs/features/developer-tooling/curated-tooling.mdx @@ -0,0 +1,16 @@ +--- +title: Ferramentas Selecionadas +--- +Essas ferramentas simplificam parte do trabalho comum de acesso e processamento de Hooks. + +| Ferramenta | Link de Referência | +| ----------------------- | -------------------------------------------------------------------- | +| **Hooks Builder** | [Link do Builder](https://builder.xahau.network/develop) | +| **Hooks Toolkit** | [Link do Toolkit](https://hooks-toolkit.com/) | +| **Xpop Toolkit** | [Link do Toolkit](https://github.com/Transia-RnD/xpop-toolkit) | +| **Hooks Blog** | [Link do Blog](https://dev.to/t/xrplhooks/top/infinity) | +| **XFL Tools** | [Link da Ferramenta](https://richardah.github.io/xfl-tools/) | +| **Binary Visualizer** | [Link da Ferramenta](https://richardah.github.io/xrpl-binary-visualizer/) | +| **Keylet Tools** | [Link da Ferramenta](https://richardah.github.io/xrpl-keylet-tools/) | +| **CTID Visualizer** | [Link da Ferramenta](https://transia-rnd.github.io/xrpl-ctid-visualizer/) | +| **C Hook Tx Builder** | [Link da Ferramenta](https://transia-rnd.github.io/xrpl-tt-visualizer/) | diff --git a/src/content/docs/br/docs/features/developer-tooling/developer-tricks.mdx b/src/content/docs/br/docs/features/developer-tooling/developer-tricks.mdx new file mode 100644 index 0000000..354c025 --- /dev/null +++ b/src/content/docs/br/docs/features/developer-tooling/developer-tricks.mdx @@ -0,0 +1,29 @@ +--- +title: Truques para Desenvolvedores +--- +## Assinatura Curinga + +Para testar e reproduzir facilmente, use `NetworkID` com o valor `65535` (config: `[network_id]`) para desabilitar a verificação de assinatura. + +Adicionado: [https://github.com/Xahau/xahaud/pull/201](https://github.com/Xahau/xahaud/pull/201) + +## Definições do Servidor + +As definições do servidor podem ser facilmente obtidas a partir dos nós públicos. Essas definições incluem informações de codec binário e outros dados específicos da rede necessários para serialização e desserialização de transações. + +### Mainnet +- [`https://xahau.network/server_definitions.json`](https://xahau.network/server_definitions.json) + +### Testnet +- [`https://xahau-test.net/server_definitions.json`](https://xahau-test.net/server_definitions.json) + +### JSHooks-Testnet +- [`https://jshooks.xahau-test.net/server_definitions.json`](https://jshooks.xahau-test.net/server_definitions.json) + +Essas definições de servidor são essenciais para: +- Operações de codec binário +- Serialização de transações +- Definições de tipos de campo +- Constantes específicas da rede + +Você pode usar essas definições em suas aplicações para codificar e decodificar corretamente transações para a rede Xahau. diff --git a/src/content/docs/br/docs/features/faucet-and-explorer.mdx b/src/content/docs/br/docs/features/faucet-and-explorer.mdx new file mode 100644 index 0000000..62ad9dd --- /dev/null +++ b/src/content/docs/br/docs/features/faucet-and-explorer.mdx @@ -0,0 +1,27 @@ +--- +title: Faucet & Explorers +--- +O Faucet e os Explorers do Xahau podem ser encontrados aqui: + +## Testnet + +* **Faucet:** [**https://xahau-test.net**](https://xahau-test.net) + * Para automatizar o financiamento de contas na testnet, faça um HTTP POST para:\ + [https://xahau-test.net/accounts](https://xahau-test.net/accounts)\ + Corpo vazio: nova conta (pré-financiada)\ + Corpo JSON com a propriedade `destination`: financia a conta `destination` mencionada. +* **Explorers:** + * **Xahauexplorer:** [**https://test.xahauexplorer.com**](https://test.xahauexplorer.com) + * **InFTF:** [**https://explorer.xahau-test.net**](https://explorer.xahau-test.net) + * **XRPL.org:** [**https://xahau-testnet.xrpl.org**](https://xahau-testnet.xrpl.org) + * **XRPLWin:** [**https://xahau-testnet.xrplwin.com**](https://xahau-testnet.xrplwin.com/) + +## Mainnet + +* **Página Inicial:** [**https://xahau.network**](https://xahau.network/) +* **Explorers:** + * **Xahauexplorer:** [**https://xahauexplorer.com**](https://xahauexplorer.com/) + * **Xahscan:** [**https://xahscan.com/**](https://xahscan.com/) + * **InFTF:** [**https://explorer.xahau.network**](https://explorer.xahau.network/) + * **XRPL.org:** [**https://xahau.xrpl.org**](https://xahau.xrpl.org) + * **XRPLWin:** [**https://xahau.xrplwin.com**](https://xahau.xrplwin.com/) diff --git a/src/content/docs/br/docs/features/governance-game.mdx b/src/content/docs/br/docs/features/governance-game.mdx new file mode 100644 index 0000000..01852b5 --- /dev/null +++ b/src/content/docs/br/docs/features/governance-game.mdx @@ -0,0 +1,199 @@ +--- +title: Jogo de Governança +description: >- + O Jogo de Governança é um mecanismo inovador de governança dentro do + ecossistema Xahau para garantir uma abordagem centrada na comunidade para a + tomada de decisões. +--- + +### Visão Geral + +O Jogo de Governança do Xahau permite que até 400 stakeholders participem democraticamente na gestão da rede Xahau por meio do Hook de Governança instalado na Conta Gênesis. + +### Camada 1 + +O jogo consiste em uma mesa de "Camada 1" com 20 assentos. Uma conta Xahau (endereço-r) pode preencher cada assento, ou ele pode estar vazio. Quando um assento é preenchido, diz-se que um membro da mesa está sentado ali. + +Para jogar o jogo, os membros da mesa votam. Os votos são sobre um de três tipos de tópicos: + +* Tópicos de Assento +* Tópicos de Hook +* Tópicos de Recompensa. + +Os tópicos de Assento são S00 a S19 e representam um voto sobre quem (se alguém) está atualmente sentado naquele assento. Um voto de 80% é suficiente para fazer uma mudança. O processo de votação é contínuo, sendo o voto final que cruza o limite que aciona a mudança. + +Os tópicos de Hook são H0 a H9 e representam quais Hooks, incluindo o próprio Hook de Governança, estão instalados na conta da mesa. Esses tópicos requerem 100% dos membros sentados naquela mesa para concordar antes que uma mudança possa ser feita. Isso permite que o Jogo de Governança seja atualizado e que mais funcionalidades da conta Gênesis sejam adicionadas ao longo do tempo. + +Os tópicos de Recompensa são RR e RD, que significam Taxa de Recompensa e Atraso de Recompensa, respectivamente. Esses tópicos também requerem 100% dos membros na mesa para concordar para fazer uma mudança. Esses parâmetros afetam o sistema de AjustesDeSaldo: quanto cada usuário ativo na rede pode reivindicar e com que frequência. + +### Camada 2 + +Os membros que preenchem assentos na mesa da Camada 1 são contas Xahau (endereços-r). O jogo de governança é projetado para ser estruturalmente recursivo, de forma que uma dessas contas pode ser ela mesma uma mesa composta por outros 20 assentos. Isso é chamado de mesa da Camada 2, e os assentos são assentos da Camada 2. + +Dentro de uma mesa da Camada 2, os mesmos tópicos de votação de assento e hook existem, com as mesmas regras de votação da mesa da Camada 1. Isso permite que uma mesa governe sua própria composição e os hooks que rodam lá. + +Além desses tópicos, uma mesa da Camada 2 também pode, por votação de 51%, levantar um voto para a mesa da Camada 1. Este é um voto em nome do endereço-r em que a mesa da Camada 2 existe e conta como um único voto na mesa da Camada 1. + +O voto da mesa da Camada 2 pode cair abaixo de 51%, caso em que o voto originalmente levantado para a mesa da Camada 1 **não** é retirado. Apenas um novo voto (diferente) atingindo 51% pode mudar o voto da mesa na Camada 1. + +As mesas da Camada 2 só podem votar em tópicos de Recompensa por meio de um voto levantado para a Camada 1. + +Em resumo, os membros da Camada 2 podem votar em: + +* Assentos e Hooks para sua própria mesa, e +* Assentos, Hooks e tópicos de Recompensa para a mesa L1 via o assento da Camada 1 em que sua mesa da Camada 2 reside. + +### Restrições do Jogo + +* Qualquer mesa pode ter pelo menos 2 membros e no máximo 20 membros. +* Um único endereço-r pode ocupar apenas um assento em uma determinada mesa, mas pode ocupar um assento em cada uma de muitas mesas diferentes. +* O Jogo de Governança não foi projetado para recursão além de duas camadas. Não há inviabilidade técnica em implementar uma mesa da Camada 3, mas o Hook de Governança atual não a suporta. + +### Recompensas de Validadores + +As recompensas de validadores são um incentivo para executar um validador na rede. As recompensas são geradas pela rede e concedidas à interseção de membros da Camada 1 e validadores UNL ativos. Para se qualificar para recompensas de validadores dentro de um dado bloco de 256 ledgers, o seguinte deve ser verdadeiro: + +* O validador está na UNL do Xahau. +* O validador valida com sucesso aos olhos de outros validadores UNL. +* Quando a chave pública mestre do validador é convertida em um endereço-r, essa conta está na Mesa L1. + +As recompensas são ad-hoc e baseadas nos Ajustes de Saldo dos usuários do Xahau. Quando um usuário realiza um Ajuste de Saldo, uma quantia igual ao seu ajuste dividido por 20 é enviada ao endereço-r de cada um dos validadores ativos que atendem aos critérios acima. + +## Especificação Técnica + +O Hook de Governança é instalado na conta gênesis pelo amendment XahauGenesis vários ledgers após o ledger 1 em uma nova rede. Esta é a mesa L1. Para criar uma mesa L2, instale o Hook em uma conta diferente e, em seguida, sente essa conta na mesa L1. + +### Parâmetros do Hook de Governança + +Quando o Hook de Governança é instalado, ele é instalado com um conjunto de HookParameters. Eles especificam a composição inicial da mesa. + +Cada HookParameter tem um nome de 3 bytes composto por 3 caracteres Ascii ou 2 caracteres Ascii e um identificador conforme abaixo. LE = Little Endian. + +``` +Nome do Parâmetro: {'I', 'R', 'R'} +Valor do Parâmetro: Taxa de Recompensa Inicial <8 bytes XFL entre 0 e 1, LE> +Nome do Parâmetro: {'I', 'R', 'D'} +Valor do Parâmetro: Atraso de Recompensa Inicial <8 bytes LE XFL em segundos entre recompensas> +Nome do Parâmetro: {'I', 'M', 'C'} +Valor do Parâmetro: Contagem de Membros Inicial <1 byte> +Nome do Parâmetro: {'I', 'S', 0x00} +Valor do Parâmetro: ID de Conta de 20 bytes do membro do assento #0 inicial. +Nome do Parâmetro: {'I', 'S', 0x01} +Valor do Parâmetro: ID de Conta de 20 bytes do membro do assento #1 inicial. +... etc ... até no máximo Assento 19. + +``` + +Para iniciar o jogo, uma transação Invoke deve ser enviada para o Hook. Ela pode ser enviada por qualquer conta. Nenhum Blob ou HookParameters são necessários. Esta transação Invoke aciona o Hook pela primeira vez e o solicita a criar entradas de estado para cada assento inicial, taxa de recompensa e atraso de recompensa. + +### Estado do Hook de Governança + +O Hook State do Hook de Governança é armazenado no namespace zero: `0000000000000000000000000000000000000000000000000000000000000000.` + +Existem vários tipos de entrada de estado. O primeiro são as chamadas chaves de membro diretas e inversas. Elas mapeiam cada número de assento para o membro que está sentado lá e cada membro para o assento em que está sentado. + +``` +Chave: 0x0000000000000000000000000000000000000000000000000000000000000005 +Val: + +Chave: +Val: 0x03 +``` + +Em seguida, há algumas entradas de estado singleton. Contagem de Membros, Taxa de Recompensa e Atraso de Recompensa, respectivamente: + +``` +Chave em Ascii: MC +Chave: 0x0000000000000000000000000000000000000000000000000000000000004D43 +Val: <1 byte de contagem de membros (quantos assentos estão ocupados)> + +Chave em Ascii: RR +Chave: 0x0000000000000000000000000000000000000000000000000000000000005252 +Val: <8 bytes LE XFL taxa de recompensa (entre 0 e 1 (1 sendo 100%))> + +Chave em Ascii: RD +Chave: 0x0000000000000000000000000000000000000000000000000000000000005244 +Val: <8 bytes LE XFL atraso de recompensa em segundos> +``` + +Por fim, votos e contadores de votos também são armazenados no estado do Hook. Quando um voto é emitido por um assento, ele é registrado no estado do Hook da seguinte forma: + +``` +A chave de voto tem 32 bytes composta por: + 'V' (0x56) - voto + 'H' (0x48) ou 'R' (0x52) ou 'S' (0x53) - tipo de tópico + 'R' (0x52) ou 'D' (0x44) ou 0 (0x00) a 19 (0x13) - detalhe do tópico + 1 (0x01) ou 2 (0x02) - camada alvo para este voto + 0x00 00 00 00 00 00 00 00 - 8 bytes de preenchimento + ID de Conta de 20 bytes - o votante +Dados do voto: + ID de Conta de 20 bytes ou XFL de 8 bytes +``` + +Quando um voto é emitido, ele incrementa uma entrada de estado contador de votos. Este contador acompanha quantos votos há atualmente para este par tópico-dados e permite que o Hook execute o voto quando a votação ultrapassa o limite necessário. O estado do contador é o seguinte: + +``` +A chave do contador tem 32 bytes composta por: + 'C' (0x43) - contagem + 'H' (0x48) ou 'R' (0x52) ou 'S' (0x53) - tipo de tópico + 'R' (0x52) ou 'D' (0x44) ou 0 (0x00) a 19 (0x13) - detalhe do tópico + 1 (0x01) ou 2 (0x02) - camada alvo para este voto + 0s para preenchimento + dados do voto ou dados do voto truncados à esquerda +``` + +### Transações do Hook de Governança + +O Hook de Governança é interagido pelos seus membros usando transações ttINVOKE. Além disso, o Hook também pode emitir suas próprias transações ttINVOKE se for uma mesa L2 levantando um voto para a mesa L1. + +Uma transação de voto contém um array HookParameters no nível superior da transação: + +``` +{ + Account: , + TransactionType: Invoke, + NetworkID: 21337, + Destination: , + HookParameters: + [ + { + HookParameter: + { + HookParameterName: "4C", // L - a camada alvo + HookParameterValue: "01", // 01 para mesa L1, 02 para mesa L2 + // nota: esta é a mesa para a qual o voto é + // destinado, não a mesa em que você está + // ou seja, para uma mesa L2 você pode votar + // em sua própria composição ou na da L1 + } + }, + { + HookParameter: + { + HookParameterName: "54", // T - tipo de tópico + HookParameterValue: "4801", // H [0x00-0x09] ou + // S [0x00-0x13] ou + // RR ou RD + } + }, + { + HookParameter: + { + HookParameterName: "56", // V - dados do voto + HookParameterValue: <32 ou 20 ou 8 bytes de dados do voto> + } + } + ] +} + +``` + +### Limpar um Voto + +Não há como "excluir um voto" em si. Você pode mudar seu voto de volta para refletir a posição atual. + +Portanto, por exemplo, se ninguém está no assento 8 e você votou para que a conta A se sente lá, e então muda de ideia, você pode fazer um voto para vacar o assento 8 (mesmo que já esteja vago), alinhando assim seu voto com o estado atual do assento. + +Para fazer isso, você vota com todos os 0s nos dados do voto, no mesmo comprimento que o tópico de voto normalmente requer. Portanto, para um voto de assento, isso equivale a 20 bytes de 0. + + diff --git a/src/content/docs/br/docs/features/http-websocket-apis/admin-api-methods.mdx b/src/content/docs/br/docs/features/http-websocket-apis/admin-api-methods.mdx new file mode 100644 index 0000000..84d076a --- /dev/null +++ b/src/content/docs/br/docs/features/http-websocket-apis/admin-api-methods.mdx @@ -0,0 +1,67 @@ +--- +title: Métodos da API Administrativa +--- +Esses métodos são destinados exclusivamente ao pessoal de confiança responsável pela manutenção das operações do servidor xahaud. + +### Métodos de Geração de Chaves + + + +| Método | Descrição | +| ------------------ | --------------------------------------------------------------------------------------------------------------------------- | +| validation_create | Gera um par de chaves formatado para nós xahaud. (Validadores devem usar tokens em vez de chaves geradas por este método.) | +| wallet_propose | Gera chaves para uma nova conta. | + +### Métodos de Registro e Gerenciamento de Dados + + + +| Método | Descrição | +| --------------- | ---------------------------------------------------------------------- | +| can_delete | Habilita a exclusão online de ledgers até um ledger especificado. | +| download_shard | Baixa um fragmento específico do histórico de ledgers. | +| ledger_cleaner | Configura o limpador de ledger para detectar e resolver dados corrompidos. | +| ledger_request | Consulta um servidor par para uma versão específica do ledger. | +| log_level | Visualiza ou altera os níveis de verbosidade do log. | +| logrotate | Reabre o arquivo de log. | +| node_to_shard | Transfere dados do armazenamento de ledger para o armazenamento de fragmentos. | + +### Métodos de Controle do Servidor + +| Método | Descrição | +| -------------- | ------------------------------------------------------------ | +| ledger_accept | Fecha e avança o ledger no modo autônomo. | +| stop | Desliga o servidor xahaud. | + +### Métodos de Assinatura + +| Método | Descrição | +| --------- | ---------------------------------------------- | +| sign | Assina criptograficamente uma transação. | +| sign_for | Contribui para uma assinatura múltipla. | + +### Métodos de Gerenciamento de Pares + +| Método | Descrição | +| ------------------------ | ------------------------------------------------------------- | +| connect | Força o servidor a se conectar a um par específico. | +| peer_reservations_add | Adiciona ou atualiza uma vaga reservada para um par específico. | +| peer_reservations_del | Remove uma vaga reservada para um par específico. | +| peer_reservations_list | Visualiza todas as vagas de pares reservadas. | +| peers | Recupera informações sobre pares conectados. | + +### Métodos de Status/Depuração + + + +| Método | Descrição | +| ---------------------- | ------------------------------------------------------------------ | +| consensus_info | Visualiza o estado atual do processo de consenso. | +| feature | Recupera informações sobre emendas de protocolo. | +| fetch_info | Verifica o status de sincronização do servidor com a rede. | +| get_counts | Visualiza estatísticas sobre os internos do servidor e uso de memória. | +| manifest | Recupera detalhes de chave pública para um validador conhecido. | +| print | Acessa informações sobre subsistemas internos. | +| validator_info | Obtém os detalhes de configuração do validador do servidor. | +| validator_list_sites | Visualiza sites que publicam listas de validadores. | +| validators | Recupera informações sobre os validadores atuais. | diff --git a/src/content/docs/br/docs/features/http-websocket-apis/considerations.mdx b/src/content/docs/br/docs/features/http-websocket-apis/considerations.mdx new file mode 100644 index 0000000..33bcbfb --- /dev/null +++ b/src/content/docs/br/docs/features/http-websocket-apis/considerations.mdx @@ -0,0 +1,16 @@ +--- +title: Considerações +--- +## Marcadores + +Alguns métodos retornam mais dados do que cabem eficientemente em uma única resposta. Quando os resultados excedem o limite de resposta, um campo `marker` é incluído na resposta. Este campo permite que você recupere páginas adicionais de dados por meio de solicitações subsequentes. Para continuar buscando dados, inclua o valor `marker` da resposta anterior em sua próxima solicitação. Se uma resposta não incluir um `marker`, significa que você chegou ao final do conjunto de dados. + +O formato do campo `marker` é intencionalmente não especificado. Cada servidor pode definir o `marker` conforme necessário, o que significa que pode ser uma string, um objeto aninhado ou outro tipo. O formato do `marker` pode variar entre servidores e até entre métodos no mesmo servidor. Cada `marker` é temporário e pode se tornar inválido após aproximadamente 10 minutos. + +## Limite de Taxa + +O servidor `xahaud` impõe limites de taxa em clientes de API que usam APIs públicas para evitar solicitações excessivas. O limite de taxa é aplicado com base no endereço IP do cliente, o que significa que múltiplos clientes compartilhando uma [tradução de endereço de rede (NAT)](https://en.wikipedia.org/wiki/Network_address_translation) compartilharão o mesmo limite de taxa associado ao seu IP público. + +Quando um cliente está se aproximando do limite de taxa, o servidor inclui um campo `"warning": "load"` no nível superior de uma resposta de API. Este aviso não aparece em todas as respostas, mas pode ser enviado várias vezes antes de o servidor desconectar o cliente. Clientes conectados como administrador estão isentos de limitação de taxa. + +Se um cliente exceder o limite de taxa, o servidor desconecta o cliente e bloqueia temporariamente novas solicitações daquele endereço IP. As APIs WebSocket e JSON-RPC lidam com desconexões de forma diferente, conforme descrito abaixo. diff --git a/src/content/docs/br/docs/features/http-websocket-apis/public-api-methods.mdx b/src/content/docs/br/docs/features/http-websocket-apis/public-api-methods.mdx new file mode 100644 index 0000000..a1e3214 --- /dev/null +++ b/src/content/docs/br/docs/features/http-websocket-apis/public-api-methods.mdx @@ -0,0 +1,89 @@ +--- +title: Métodos da API Pública +--- +Interaja diretamente com um servidor xahaud usando métodos de API pública. Esses métodos não são necessariamente destinados ao uso público geral, mas são acessíveis a qualquer cliente conectado ao servidor. + +### Métodos de Conta + + + +| Método | Descrição | +| ------------------- | -------------------------------------------------------------------------- | +| account_channels | Lista canais de pagamento onde a conta é a origem do canal. | +| account_currencies | Lista moedas que a conta pode enviar ou receber. | +| account_info | Recupera informações básicas sobre uma conta. | +| account_lines | Acessa informações de linha de confiança para uma conta. | +| account_objects | Recupera todos os objetos do ledger pertencentes a uma conta. | +| account_offers | Visualiza as ofertas de câmbio de moeda de uma conta. | +| account_tx | Recupera o histórico de transações de uma conta. | +| gateway_balances | Calcula os valores totais emitidos para uma conta. | +| noripple_check | Sugere alterações para as configurações Default Ripple e No Ripple de uma conta. | + +### Métodos de Ledger + + + +| Método | Descrição | +| --------------- | ------------------------------------------------------ | +| ledger | Obtém informações sobre uma versão específica do ledger. | +| ledger_closed | Recupera a versão de ledger fechada mais recentemente. | +| ledger_current | Recupera a versão atual do ledger em funcionamento. | +| ledger_data | Acessa o conteúdo bruto do ledger. | +| ledger_entry | Recupera um elemento específico de uma versão do ledger. | + +### Métodos de Transação + + + +| Método | Descrição | +| ------------------- | -------------------------------------------------------------- | +| submit | Envia uma transação para a rede. | +| submit_multisigned | Envia uma transação com múltiplas assinaturas. | +| transaction_entry | Recupera detalhes sobre uma transação em um ledger específico. | +| tx | Recupera informações de transação em todos os ledgers. | +| sign | (Admin) Assina criptograficamente uma transação. | +| sign_for | (Admin) Contribui para uma assinatura múltipla. | + +### Métodos de Livro de Ofertas + +| Método | Descrição | +| ------------------- | ------------------------------------------------------------------ | +| book_offers | Visualiza ofertas para troca de duas moedas. | +| deposit_authorized | Verifica se uma conta pode enviar pagamentos diretamente para outra. | + +### Métodos de Canal de Pagamento + + + +| Método | Descrição | +| ------------------ | -------------------------------------------------- | +| channel_authorize | Assina uma reivindicação para um canal de pagamento. | +| channel_verify | Verifica a assinatura de uma reivindicação de canal de pagamento. | + +### Métodos de Assinatura + + + +| Método | Descrição | +| ----------- | -------------------------------------- | +| subscribe | Escuta atualizações sobre um assunto. | +| unsubscribe | Para de receber atualizações. | + +### Métodos de Informações do Servidor + +| Método | Descrição | +| ------------- | ------------------------------------------------------ | +| fee | Recupera informações sobre custos de transação. | +| server_info | Obtém o status do servidor em formato legível por humanos. | +| server_state | Obtém o status do servidor em formato legível por máquina. | +| manifest | Recupera detalhes de chave pública para um validador. | + +### Métodos Utilitários + + + +| Método | Descrição | +| ------ | ------------------------------------------------------------------------------ | +| json | Proxy para executar comandos com parâmetros JSON. _(Somente linha de comando.)_ | +| ping | Verifica a conectividade com o servidor. | +| random | Gera números aleatórios. | diff --git a/src/content/docs/br/docs/features/http-websocket-apis/request-formatting-guide.mdx b/src/content/docs/br/docs/features/http-websocket-apis/request-formatting-guide.mdx new file mode 100644 index 0000000..091740b --- /dev/null +++ b/src/content/docs/br/docs/features/http-websocket-apis/request-formatting-guide.mdx @@ -0,0 +1,63 @@ +--- +title: Guia de Formatação de Requisições +--- +### Servidores Públicos + +* wss://xahau.network ou https://xahau.network (Mainnet) +* wss://xahau-test.net ou https://xahau-test.net (Testnet) + +### Exemplos de Requisições + +Para enviar uma requisição de exemplo para a API, use os seguintes comandos. + +### Websocket + +``` +{ + "id": 3, + "command": "account_info", + "account": "rhBDFMmr3jSjgsWMqBAYaATLy3PuXy395y", + "strict": true, + "ledger_index": "validated", + "api_version": 1 +} +``` + +### Estrutura de Requisição WebSocket + +Após estabelecer uma conexão WebSocket com o servidor `xahaud`, você pode enviar comandos como objetos JSON com estes campos: + +
CampoTipoDescrição
commandStringO nome do método da API
id(Múltiplo)(Opcional) Identificador único para a requisição.
api_versionNúmero(Opcional) Especifica a versão da API.
+ +### JSON-RPC + +``` +POST https://xahau.network/ +Content-Type: application/json + +{ + "method": "account_info", + "params": [ + { + "account": "rhBDFMmr3jSjgsWMqBAYaATLy3PuXy395y", + "strict": true, + "ledger_index": "validated", + "api_version": 1 + } + ] +} +``` + +### Estrutura de Requisição JSON-RPC + +
CampoTipoDescrição
methodStringO nome do método da API
paramsArray(Opcional) Um array de um item contendo um objeto JSON com os parâmetros do método.
+ +### Linha de Comando + +``` +xahaud account_info rhBDFMmr3jSjgsWMqBAYaATLy3PuXy395y validated strict +``` + +### Estrutura de Requisição por Linha de Comando + +
CampoDescrição
xahaudInicia a chamada ao serviço xahaud
methodO nome do método da API
params(Opcional)
diff --git a/src/content/docs/br/docs/features/http-websocket-apis/response-formatting-guide.mdx b/src/content/docs/br/docs/features/http-websocket-apis/response-formatting-guide.mdx new file mode 100644 index 0000000..87dff60 --- /dev/null +++ b/src/content/docs/br/docs/features/http-websocket-apis/response-formatting-guide.mdx @@ -0,0 +1,29 @@ +--- +title: Guia de Formatação de Respostas +--- +As respostas são estruturadas de forma diferente dependendo se a requisição é feita por meio das interfaces WebSocket, JSON-RPC ou Linha de Comando. As interfaces JSON-RPC e Linha de Comando compartilham o mesmo formato, pois a interface de Linha de Comando usa JSON-RPC internamente. + +### Campos + +| Campo | Tipo | Descrição | +| ------------- | -------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| id | (Varia) | (Para WebSocket) O ID da requisição original. | +| status | String | (Para WebSocket) Indica `success` quando a requisição foi recebida e processada corretamente. | +| result.status | String | (Para JSON-RPC e Linha de Comando) Indica `success` quando a requisição foi processada com sucesso. | +| type | String | (Para WebSocket) O valor `response` é usado para respostas diretas a requisições de API. Notificações assíncronas usam outros valores, como `ledgerClosed` ou `transaction`. | +| result | Objeto | Contém o resultado da consulta, com conteúdo que varia por comando. | +| warning | String | _(Opcional)_ Se presente, o valor é `load`, indicando que o cliente está se aproximando do limite de taxa onde o servidor pode desconectar. | +| warnings | Array | _(Opcional)_ Uma lista de **Objetos de Aviso** com avisos importantes do servidor. Para mais detalhes, consulte Avisos de API. | +| forwarded | Boolean | _(Opcional)_ `true` indica que a requisição foi encaminhada de um servidor em Modo de Relatório para um servidor P2P para atender a requisição. O padrão é `false`. | + +Avisos de API + +Quando uma resposta contém um array `warnings`, cada entrada representa um aviso específico do servidor. Cada **Objeto de Aviso** inclui os seguintes campos: + + + +| Campo | Tipo | Descrição | +| ------- | ------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| id | Número | Um código numérico único que identifica esta mensagem de aviso. | +| message | String | Uma explicação legível por humanos do aviso. Evite escrever código que dependa do conteúdo deste campo; use o `id` (e `details`, se disponível) para interpretar o aviso. | +| details | Objeto | _(Opcional)_ Contexto adicional sobre o aviso. O conteúdo varia por tipo de aviso. | diff --git a/src/content/docs/br/docs/features/network-features/account-managment.mdx b/src/content/docs/br/docs/features/network-features/account-managment.mdx new file mode 100644 index 0000000..86335e0 --- /dev/null +++ b/src/content/docs/br/docs/features/network-features/account-managment.mdx @@ -0,0 +1,44 @@ +--- +title: Gerenciamento de Conta +--- +import { LinkCard } from '@astrojs/starlight/components'; + +Os recursos de Gerenciamento de Conta na rede Xahau são um componente crucial para que os usuários gerenciem suas contas de forma eficaz. + +Isso inclui vários tipos de transação que permitem aos usuários realizar diversas operações em suas contas. + +### Tipos de Transação + +#### AccountSet + +O tipo de transação `AccountSet` permite que os usuários modifiquem as propriedades de suas contas. Isso inclui configurações como taxa de transferência, flags de conta e muito mais. + + + +#### AccountDelete + +O tipo de transação `AccountDelete` permite que os usuários excluam suas contas da rede Xahau. Esta operação é irreversível e deve ser usada com cautela. + + + +#### SetRegularKey + +O tipo de transação `SetRegularKey` permite que os usuários definam um par de chaves regular para sua conta. Este par de chaves pode ser usado como alternativa ao par de chaves mestre para assinar transações. + + + +#### SignerListSet + +O tipo de transação `SignerListSet` permite que os usuários definam uma lista de signatários para sua conta. Isso é particularmente útil para contas com múltiplas assinaturas, onde múltiplas partes precisam aprovar as transações. + + + +#### Import + +O tipo de transação `Import` é usado para importar transações de outras redes. Esse recurso é especialmente útil para emissores que precisam importar transações para seus detentores de ativos. Recomenda-se configurar as chaves de suas contas antes de tentar importar transações. + +Observe que o processo de importação para o emissor envolve tipos de transação específicos e requer configuração cuidadosa. Sempre certifique-se de que os hooks estejam configurados corretamente e que as transações sejam válidas para as operações pretendidas. + + + +Esses tipos de transação fornecem aos usuários um conjunto abrangente de ferramentas para gerenciar suas contas na rede Xahau. Como em todas as operações, os usuários devem garantir que compreendem as implicações de cada tipo de transação antes de usá-los. diff --git a/src/content/docs/br/docs/features/network-features/balance-rewards.mdx b/src/content/docs/br/docs/features/network-features/balance-rewards.mdx new file mode 100644 index 0000000..8445efc --- /dev/null +++ b/src/content/docs/br/docs/features/network-features/balance-rewards.mdx @@ -0,0 +1,20 @@ +--- +title: Recompensas de Saldo +--- +import { LinkCard } from '@astrojs/starlight/components'; + +O recurso de Recompensas de Saldo é um aspecto único da rede Xahau que permite aos usuários acumular e reivindicar recompensas com base no saldo de sua conta. Esse recurso é implementado por meio de uma combinação de código nativo (Emenda BalanceRewards) e código de hook (Hook de Recompensa da Conta Gênesis). + +### Tipos de Transação + +#### ClaimReward + +Uma transação `ClaimReward` permite que uma conta reivindique as recompensas acumuladas. As recompensas podem ser reivindicadas pelo proprietário da conta ou por um emissor especificado. A conta também pode optar por não receber recompensas definindo o campo Flags como 1. + + + +#### GenesisMint + +O tipo de transação `GenesisMint` também está associado ao recurso de Recompensas de Saldo. Esta é uma transação Emitida que é executada por meio do Hook de Recompensa toda vez que um usuário reivindica recompensas de saldo. + + diff --git a/src/content/docs/br/docs/features/network-features/check.mdx b/src/content/docs/br/docs/features/network-features/check.mdx new file mode 100644 index 0000000..8c4352c --- /dev/null +++ b/src/content/docs/br/docs/features/network-features/check.mdx @@ -0,0 +1,26 @@ +--- +title: Cheque +--- +import { LinkCard } from '@astrojs/starlight/components'; + +O recurso Cheque na rede Xahau é um sistema de pagamento diferido que permite a criação, cancelamento e compensação de cheques dentro do ledger. Esse recurso é projetado para facilitar transações seguras e eficientes entre partes. + +### Tipos de Transação + +#### CheckCreate + +A transação `CheckCreate` é usada para criar um objeto Cheque no ledger. Isso representa um pagamento diferido que pode ser compensado pelo destinatário pretendido. + + + +#### CheckCancel + +A transação `CheckCancel` é usada para cancelar um Cheque que foi criado mas ainda não compensado. Isso permite que o remetente interrompa o processamento do pagamento, se necessário. + + + +#### CheckCash + +A transação `CheckCash` é usada para compensar um Cheque que foi criado. Isso permite que o destinatário receba os fundos que foram diferidos. + + diff --git a/src/content/docs/br/docs/features/network-features/escrow.mdx b/src/content/docs/br/docs/features/network-features/escrow.mdx new file mode 100644 index 0000000..7d2f660 --- /dev/null +++ b/src/content/docs/br/docs/features/network-features/escrow.mdx @@ -0,0 +1,28 @@ +--- +title: Escrow +--- +import { LinkCard } from '@astrojs/starlight/components'; + +O recurso Escrow é uma parte crucial da rede Xahau. Ele fornece um método seguro e sem necessidade de confiança para transações entre partes. O recurso Escrow garante que os ativos envolvidos em uma transação sejam mantidos em segurança até que todas as condições da transação sejam atendidas. + +### Tipos de Transação + +O recurso Escrow inclui três tipos de transação: + +#### EscrowCreate + +A transação `EscrowCreate` é usada para criar um novo acordo de escrow. Esta transação especifica os termos do escrow, incluindo as partes envolvidas, os ativos a serem mantidos em escrow e as condições sob as quais os ativos serão liberados. + + + +#### EscrowFinish + +A transação `EscrowFinish` é usada para concluir um acordo de escrow. Esta transação é executada quando todas as condições do escrow são atendidas. Após a execução, os ativos mantidos em escrow são liberados para a parte apropriada. + + + +#### EscrowCancel + +A transação `EscrowCancel` é usada para cancelar um acordo de escrow. Esta transação pode ser executada se as condições do escrow não forem atendidas dentro de um prazo especificado. Após o cancelamento, os ativos mantidos em escrow são devolvidos à parte que iniciou o escrow. + + diff --git a/src/content/docs/br/docs/features/network-features/hooks.mdx b/src/content/docs/br/docs/features/network-features/hooks.mdx new file mode 100644 index 0000000..4fb09f0 --- /dev/null +++ b/src/content/docs/br/docs/features/network-features/hooks.mdx @@ -0,0 +1,22 @@ +--- +title: Hooks +--- +import { LinkCard } from '@astrojs/starlight/components'; + +Os Hooks são um recurso poderoso da rede XRPL, fornecendo funcionalidade robusta de contratos inteligentes. São módulos WebAssembly pequenos e eficientes projetados especificamente para o XRPL, e podem ser referidos como Contratos Inteligentes para o Protocolo XRP Ledger. Os Hooks podem ser escritos em qualquer linguagem compilável com WebAssembly, permitindo que uma ampla gama de lógicas de negócios e conceitos de contratos inteligentes seja implementada. + +### Tipos de Transação + +O recurso Hooks inclui dois tipos de transação: + +**SetHook** + +Este tipo de transação é usado para configurar um hook em uma conta. + + + +**Invoke** + +Este tipo de transação é usado para chamar ou invocar a funcionalidade de um hook. + + diff --git a/src/content/docs/br/docs/features/network-features/offer.mdx b/src/content/docs/br/docs/features/network-features/offer.mdx new file mode 100644 index 0000000..e1d5e4c --- /dev/null +++ b/src/content/docs/br/docs/features/network-features/offer.mdx @@ -0,0 +1,20 @@ +--- +title: Oferta +--- +import { LinkCard } from '@astrojs/starlight/components'; + +O recurso Oferta na rede Xahau é um componente crucial do sistema de câmbio descentralizado. Ele permite que os usuários criem e cancelem ofertas, facilitando um ambiente de negociação dinâmico e responsivo. + +### Tipos de Transação + +#### OfferCreate + +A transação `OfferCreate` é usada para colocar uma oferta na exchange descentralizada. + + + +#### OfferCancel + +A transação `OfferCancel` é usada para cancelar uma oferta existente. A documentação para este tipo de transação é referenciada na Documentação Xahau, mas não foi fornecida no contexto dado. + + diff --git a/src/content/docs/br/docs/features/network-features/payments.mdx b/src/content/docs/br/docs/features/network-features/payments.mdx new file mode 100644 index 0000000..c00b259 --- /dev/null +++ b/src/content/docs/br/docs/features/network-features/payments.mdx @@ -0,0 +1,46 @@ +--- +title: Pagamentos +--- +import { LinkCard } from '@astrojs/starlight/components'; + +O recurso Pagamentos na rede Xahau é um componente crucial que permite a transferência de ativos e fundos dentro da rede. Esse recurso é projetado para facilitar transações contínuas, garantindo uma operação suave e eficiente da rede. + +### Tipos de Transação + +O recurso Pagamentos compreende vários tipos de transação, cada um servindo a um propósito único na rede. Aqui está uma breve visão geral de cada tipo de transação: + +**DepositPreauth** + +Este tipo de transação permite que uma conta pré-autorize transações recebidas de uma fonte especificada. É uma forma de adicionar contas a uma lista de permissões, garantindo que apenas transações autorizadas sejam processadas. + + + +**TrustSet** + +Este tipo de transação permite que os usuários criem uma linha de confiança com outra conta. É uma forma de estabelecer confiança entre duas contas, permitindo que elas transacionem entre si. + + + +**Payment** + +Este é o tipo de transação básico que permite a transferência de ativos entre contas. É o tipo de transação fundamental para qualquer operação de pagamento na rede. + + + +**PaymentChannelCreate** + +Este tipo de transação permite a criação de um canal de pagamento entre duas contas. Os canais de pagamento são soluções de escalabilidade fora do ledger que possibilitam transações de alta frequência e baixo custo entre duas partes. + + + +**PaymentChannelFund** + +Este tipo de transação permite que uma conta financie um canal de pagamento existente. É uma forma de adicionar mais ativos a um canal de pagamento, possibilitando mais transações. + + + +**PaymentChannelClaim** + +Este tipo de transação permite que uma conta reivindique os fundos de um canal de pagamento. É uma forma de fechar um canal de pagamento e recuperar os ativos restantes. + + diff --git a/src/content/docs/br/docs/features/network-features/uritoken.mdx b/src/content/docs/br/docs/features/network-features/uritoken.mdx new file mode 100644 index 0000000..2cf9d25 --- /dev/null +++ b/src/content/docs/br/docs/features/network-features/uritoken.mdx @@ -0,0 +1,32 @@ +--- +title: URIToken +--- +import { LinkCard } from '@astrojs/starlight/components'; + +Os URITokens são a implementação de Token Não Fungível (NFT) nativa da rede Xahau. Eles existem como objetos de primeira classe no ledger, identificados de forma única pelo hash de seu emissor e Identificador de Recurso Uniforme (URI). Os URITokens podem apontar para qualquer conteúdo digital, com apenas um objeto por URI por conta existindo no ledger. + +O emissor tem a capacidade de definir um flag para habilitar a queima do objeto no futuro. A reserva de cada proprietário também fica bloqueada mediante a propriedade do URIToken. + +### Tipos de Transação + +#### URITokenMint + +A transação URITokenMint cunha um novo URIToken e atribui a propriedade à conta especificada. O URIToken cunhado representa um ativo digital único que pode ser usado em várias aplicações. O emissor pode optar por permitir que o URIToken cunhado seja destruído no futuro. + + + +#### URITokenBurn + +A transação URITokenBurn é usada para queimar um URIToken no Xahau. Queimar um URIToken o remove permanentemente de circulação. A transação não possui requisitos especiais de custo de transação. A conta que possui o URIToken a ser queimado é necessária para esta transação. + + + +#### URITokenBuy + +A transação URITokenBuy permite que um usuário compre um URIToken do emissor. Esta transação é usada para transferir a propriedade de um URIToken do emissor para o comprador. A conta do comprador, o identificador único do URIToken a ser comprado e o valor da moeda a pagar pelo URIToken são necessários para esta transação. + + + + + + diff --git a/src/content/docs/br/docs/features/public-nodes-rpc.mdx b/src/content/docs/br/docs/features/public-nodes-rpc.mdx new file mode 100644 index 0000000..a9218a7 --- /dev/null +++ b/src/content/docs/br/docs/features/public-nodes-rpc.mdx @@ -0,0 +1,34 @@ +--- +title: Nós Públicos (RPC) +description: >- + Executar seu próprio nó: incrível. Quer começar rapidamente? Use os nós RPC + públicos do Xahau. +--- +## Mainnet (rede 21337) + +* Websocket + * `wss://xahau.network` + * `wss://xahau.org` (alias; alguns bloqueadores de anúncios bloqueiam .network) +* HTTP POST RPC + * `https://xahau.network` + * `https://xahau.org` (alias; alguns bloqueadores de anúncios bloqueiam .network) +* Definições de Rede (Binary Codec, ...) + * [`https://xahau.network/server_definitions.json`](https://xahau.network/server_definitions.json) + +## Testnet (rede 21338) + +* Websocket + * `wss://xahau-test.net` +* HTTP POST RPC + * `https://xahau-test.net` +* Definições de Rede (Binary Codec, ...) + * [`https://xahau-test.net/server_definitions.json`](https://xahau-test.net/server_definitions.json) + +## JSHooks-Testnet (rede 31338) + +* Websocket + * `wss://jshooks.xahau-test.net` +* HTTP POST RPC + * `https://jshooks.xahau-test.net` +* Definições de Rede (Binary Codec, ...) + * [`https://jshooks.xahau-test.net/server_definitions.json`](https://jshooks.xahau-test.net/server_definitions.json) diff --git a/src/content/docs/br/docs/features/transaction-signing/index.mdx b/src/content/docs/br/docs/features/transaction-signing/index.mdx new file mode 100644 index 0000000..3bb8869 --- /dev/null +++ b/src/content/docs/br/docs/features/transaction-signing/index.mdx @@ -0,0 +1,65 @@ +--- +title: Assinatura de Transações +description: >- + Como as redes habilitadas para Hooks exigem campos de transação específicos e + oferecem mais tipos de transação, nem todos os clientes funcionarão imediatamente. + `xrpl-accountlib` +--- +## Principais Diferenças + +1. Redes habilitadas para Hooks permitem obter definições de rede dinamicamente. Isso permite que os clientes se adaptem aos tipos de transação, objetos de ledger, propriedades e tipos de valor disponíveis. Quando implementado corretamente, as bibliotecas de assinatura e codificação não precisam ser atualizadas quando a rede adiciona tipos/propriedades de transação/objeto. **As bibliotecas abaixo implementam isso e cuidarão disso por você.** +2. Redes habilitadas para Hooks exigem um **NetworkID** em cada transação para evitar a repetição de transações em outra cadeia. O **NetworkID** também será retornado por um comando RPC `server_info` no campo `network_id` (ex: **`21338`** para Hooks V3 testnet) +3. Transações em uma rede habilitada para Hooks podem precisar de taxas mais altas para entregar uma transação a outra conta, com base nos Hooks que serão executados ao sair da conta de envio e ao receber na conta de destino. Uma taxa razoável para satisfazer a execução dos Hooks pode ser obtida dinamicamente de um nó emitindo o comando `fee` enquanto fornece uma transação como `tx_blob`. **As bibliotecas abaixo implementam isso e cuidarão disso por você.** + +## JavaScript/Typescript + +O [**pacote npm `xrpl-accountlib`**](https://www.npmjs.com/package/xrpl-accountlib) pode assinar transações para redes habilitadas para Hooks, pois oferece suporte completo a recursos de rede dinâmicos, buscando definições de rede em tempo de execução. + +O [**pacote npm `xrpl-client`**](https://www.npmjs.com/package/xrpl-client) se integra perfeitamente com `xrpl-accountlib` (e vem como dependência) para buscar dinamicamente as definições de rede e valores de conta mencionados acima, auxiliando no envio da transação. + +### Exemplo de Código + +```javascript +import { + derive, + utils, + signAndSubmit, +} from "xrpl-accountlib" + +const wss = 'wss://xahau-test.net' +const account = derive.familySeed("s...") + +const networkInfo = await utils.txNetworkAndAccountValues(wss, account) + +const tx = { + TransactionType: "SetHook", + Hooks: [ { Hook: { + CreateCode: "0061736D01000000011C0460057F7F7F7F7F017E60037F7F7E017E60027F7F017F60017F017E02230303656E76057472616365000003656E7606616363657074000103656E76025F670002030201030503010002062B077F0141B088040B7F004180080B7F0041A6080B7F004180080B7F0041B088040B7F0041000B7F0041010B07080104686F6F6B00030AC4800001C0800001017F230041106B220124002001200036020C41920841134180084112410010001A410022002000420010011A41012200200010021A200141106A240042000B0B2C01004180080B254163636570742E633A2043616C6C65642E00224163636570742E633A2043616C6C65642E22", + Flags: 1, + HookApiVersion: 0, + HookNamespace: "F".repeat(64), + HookOn: "F".repeat(58) + "BFFFFE", + } + }], + ...networkInfo.txValues, + // ^^ Isso adiciona valores buscados automaticamente para você: + // Sequence, Account, LastLedgerSequence, + // Fee (Hooks habilitado: detecção automática (do ledger)) +} + +/** + * Nota: o código acima e `signAndSubmit` resultam na busca e definição + * automática de uma taxa para você. Se quiser verificar a taxa + * para mín/máx/..., obtenha sua própria taxa (string em drops) usando: + * utils.networkTxFee(wss, tx) + * + * ex: + * const Fee = await utils.networkTxFee(wss, tx) + * assert(Number(Fee) < 50_000, "Taxa automática acima de 50k drops, abortar") + * Object.assign(tx, { Fee, }) + */ + +const submitted = await signAndSubmit(tx, wss, account) + +console.log(submitted) +``` diff --git a/src/content/docs/br/docs/features/transaction-signing/transaction-fees.mdx b/src/content/docs/br/docs/features/transaction-signing/transaction-fees.mdx new file mode 100644 index 0000000..6cdb34d --- /dev/null +++ b/src/content/docs/br/docs/features/transaction-signing/transaction-fees.mdx @@ -0,0 +1,56 @@ +--- +title: Taxas de Transação +description: >- + Os contratos inteligentes Xahau (Hooks) precisam de taxas específicas por transação + e destino. Você pode facilmente obter a taxa necessária pelo comando RPC `fee`. +--- +import { Aside } from '@astrojs/starlight/components'; + +Embora as bibliotecas possam lidar com a determinação de taxas para você, ao construir suas próprias integrações com a Rede Xahau, pode ser necessário implementar a determinação dinâmica de taxas com base na transação e nas contas de origem e destino. + +Como o remetente de uma transação terá que pagar as taxas exigidas pelos Hooks invocados para o tipo de transação específico, onde os Hooks podem estar tanto na conta de origem quanto na de destino, você pode enviar um TX Blob (assinado com uma conta fictícia) para o comando `fee`, após o qual o Xahau retornará as taxas específicas necessárias para a transação. + +### Helper RPC de Taxa + +As taxas de transação em um ledger com a Emenda Hooks habilitada tornam-se não triviais para calcular por usuários finais e/ou aplicações de carteira. Isso ocorre porque hooks fortes devem ser pagos pelo originador de uma transação, e pode haver até 4 hooks fortes na conta de envio e 4 na conta de recebimento, além de outros stakeholders transacionais fortes envolvidos (como pode ser o caso com alguns tipos de transação exóticos). Além disso, se a transação for um SetHook, o tamanho dos parâmetros, o tamanho do código e se é uma operação de _criação_ ou _instalação_ determinam o tamanho da taxa. + +Portanto, é altamente recomendado que **todas** as transações sejam processadas pela chamada RPC de taxa atualizada antes de serem enviadas ao ledger. + +#### Para invocar a chamada RPC: + +1. Abra uma conexão WebSocket com o nó Hooks com o qual você trabalhará. +2. Componha a transação serializada para a qual deseja saber a taxa com o seguinte: + +* `Fee: 0` +* `SigningPubKey: ""` (Ou seja: VL de 0 byte do tipo 0x73. Em hex:`0x7300`.) +* **Não** assine a transação. + +3. Envie-a como um blob hexadecimal para o RPC da seguinte forma: + +```json +{"command":"fee", "tx_blob":""} +``` + +Para HTTP POST RPC, envie da seguinte forma: + +```json +{"method":"fee", "params": [{"tx_blob":""}] } +``` + +A resposta deve ser algo como + +```json +{ + result: { + drops: { + base_fee: '130520', + }, + //... + }, + type: 'response' +} +``` + +Pegue a taxa base e defina-a como o campo `Fee` na transação. Agora assine e envie conforme o processo normal de envio de transações. + +Se houver um valor inválido para `tx_blob` ou `tx_blob` estiver ausente, um resultado JSON regular será retornado com uma `base_fee` de 10. diff --git a/src/content/docs/br/docs/features/versioning-process.mdx b/src/content/docs/br/docs/features/versioning-process.mdx new file mode 100644 index 0000000..2d82c5c --- /dev/null +++ b/src/content/docs/br/docs/features/versioning-process.mdx @@ -0,0 +1,64 @@ +--- +title: Processo de Versionamento +description: >- + Este documento descreve nosso fluxo de trabalho de versionamento no GitHub, + para agilizar o desenvolvimento, testes e implantação de novas funcionalidades + e correções. +--- +import { Aside } from '@astrojs/starlight/components'; + +Este documento descreve o processo de versionamento que usamos em nosso repositório no GitHub. Utilizamos um fluxo de trabalho com três branches: `dev`, `candidate` e `release`. Esse processo garante que todas as novas funcionalidades e correções sejam cuidadosamente testadas antes do lançamento. + +### Branch Dev + +O branch dev é o branch principal para o desenvolvimento contínuo. Todas as novas funcionalidades, correções de bugs e melhorias são mescladas neste branch. É o branch mais ativo e é onde os desenvolvedores devem basear seu trabalho. + +Para contribuir com o branch dev, siga estes passos: + +1. Faça um fork do repositório para sua própria conta no GitHub. +2. Clone o repositório forkado para sua máquina local. +3. Crie um novo branch para sua funcionalidade ou correção de bug. +4. Faça suas alterações e faça commit delas no seu branch. +5. Faça push do seu branch para o repositório forkado no GitHub. +6. Crie um pull request do seu branch para o branch dev no repositório principal. + + + +Os mantenedores do código revisarão seu pull request e fornecerão feedback. Uma vez que o código for aprovado, ele será mesclado no branch dev. + +### Branches Candidate + +Assim que as funcionalidades no branch `dev` estiverem prontas para testes, elas são mescladas em um branch `candidate`. Este branch serve como área de preparação para código que está quase pronto para lançamento. + +O código no branch `candidate` é testado minuciosamente. Quaisquer bugs ou problemas encontrados são corrigidos no branch `dev` e então mesclados de volta no branch `candidate`. + +O branch `candidate` normalmente fica nessa fase de testes por cerca de 2 semanas. No entanto, esse período pode ser maior ou menor, dependendo da urgência das correções ou do tamanho das novas funcionalidades. + +1. Crie um novo branch `candidate` a partir do `dev`. +2. Crie um PR do branch `candidate` para o branch `release` com um nome como "Proposto." +3. Atualize a "Visão Geral de Alto Nível da Mudança" para incluir os Pull Requests do `candidate`. Atualize o "Contexto da Mudança" para incluir quaisquer notas adicionais sobre os PRs. + +### Branch Release + +Após o código no branch `candidate` ter sido testado minuciosamente e todos os problemas terem sido resolvidos, ele é mesclado no branch `release`. Esta é a etapa final antes do lançamento do código. + +O branch `release` contém o código que está atualmente em produção ou está prestes a ser lançado. Somente código totalmente testado e estável deve estar neste branch. + +Uma vez que o código esteja no branch `release`, ele é marcado com um número de versão. Este número de versão é usado para rastrear o lançamento e também é usado ao criar notas de lançamento. + +No branch `release`, um binário é construído e publicado em https://build.xahau.tech/. Este binário é o produto final entregue aos usuários finais. + +Para lançar o código, siga estes passos: + +1. Mescle o pull request do `candidate` no branch release. +2. Exclua o branch `candidate`. + + + +### Resumo + +Este fluxo de trabalho com três branches garante que todo o código seja testado minuciosamente antes do lançamento. Ele nos permite detectar e corrigir problemas antes que cheguem à produção e fornece um caminho claro para mover o código do desenvolvimento ao lançamento. O uso de uma LAN personalizada para testes e métricas de perfil garante que nosso código não seja apenas funcional, mas também eficiente e performático. diff --git a/src/content/docs/br/docs/hooks/concepts/chaining.mdx b/src/content/docs/br/docs/hooks/concepts/chaining.mdx new file mode 100644 index 0000000..673c860 --- /dev/null +++ b/src/content/docs/br/docs/hooks/concepts/chaining.mdx @@ -0,0 +1,47 @@ +--- +title: Chaining +description: Chain multiple hooks together to do more useful tasks +--- +import { Aside } from '@astrojs/starlight/components'; + + + +### History + +In the early days of Hooks it was only possible to install one Hook per account. This meant users were forced to produce omnibus Hooks if they wanted to do more than one thing: for example offset carbon and firewall at the same time. + +This was counter to the Hook Design Philosophy, so Hook Chaining was introduced. + +### Chaining + +A Hook Chain is a sequence of up to **10** Hooks installed on an Xahau account. + +* A Hook Chain executes successfully when every Hook in the chain has been individually executed and subsequently calls [accept](/docs/hooks/functions/control/accept). +* Each chain's execution starts at chain position 0 and ends at chain position 9. If a position is blank (because it was never filled or because the hook that was installed there has been removed) then that position is skipped and treated as successful. +* In order for a transaction to succeed, both ends of the transaction (sending side and receiving side) must have executed successfully. This means if there is a Hook Chain installed on both sides, then both Hook Chains must execute successfully for the transaction to succeed. + +Hooks are installed into the chain using the [SetHook Transaction](/docs/hooks/concepts/sethook-transaction). When they are installed, the installer may specify install-time [Parameters](/docs/hooks/concepts/parameters) which may change the behaviour of the installed Hook. + +
+![Example: Execution flow for a transaction passing through two Hook Chains](/assets/spaces_m6f29os4wP16vCS4lHNh_uploads_0OucxySTRinbe13SITJT_5561b32-sethook-Page-3.png) +
*Example: Execution flow for a transaction passing through two Hook Chains*
+
+ +### Chain Manipulation + +In addition to the _install-time_ operations specified in the [SetHook Transaction](/docs/hooks/concepts/sethook-transaction), Hooks have some runtime control over chain execution: + +* A Hook may determine its own `HookHash` by calling [hook_hash](/docs/hooks/functions/hook-context/hook_hash). +* A Hook may determine its location in the Hook Chain using [hook_pos](/docs/hooks/functions/hook-context/hook_pos). +* A Hook may skip (or re-enable) another Hook further down the chain using [hook_skip](/docs/hooks/functions/hook-context/hook_skip). +* A Hook may modify the [Parameters](/docs/hooks/concepts/parameters) of a Hook further down the chain using [hook_param_set](/docs/hooks/functions/hook-context/hook_param_set). + +### Weak Executions + +Hook Chains are [Strongly Executed](/docs/hooks/concepts/weak-and-strong). However any Hook in any chain may flag that it requires a second, Weak Execution by calling [hook_again](/docs/hooks/functions/hook-context/hook_again). If all Hook Chains execute successfully then the originating transaction is applied. Once the originating transaction has been applied any Weak Executions may happen, in the following order: + +1. `cbak` execution if this was an Emitted Transaction. +2. Weak Transactional Stake Holders who have opted in to allow a [Collect Call](/docs/hooks/concepts/collect-call). Execution order is first-come first-serve according to the event that caused the TSH to be flagged (such as pathing). +3. Any _Again as Weak_ (AAW) Hooks. Execution order for AAW is first numerically according to Account ID then numerically according to Hook position. diff --git a/src/content/docs/br/docs/hooks/concepts/collect-call.mdx b/src/content/docs/br/docs/hooks/concepts/collect-call.mdx new file mode 100644 index 0000000..fa36ba2 --- /dev/null +++ b/src/content/docs/br/docs/hooks/concepts/collect-call.mdx @@ -0,0 +1,27 @@ +--- +title: Collect Call +--- +import { Card, Aside } from '@astrojs/starlight/components'; + + +_Every party affected by a transaction should have the opportunity to have their hooks executed._ + + +When hooks are not Strongly Executed it is unfair to bill the originating transaction for their execution. For example an _OfferCreate_ which crosses 20 offers on the DEX should not be forced to pay for the execution of each of those account's Hooks. + +Therefore during typical Weak execution the fee for the execution is collected from the owner of the Hook. To enable this: + +* The Hook owner must have set `asfTshCollect` on their Xahau account using the AccountSet transaction. +* The Hook owner must have set `hsfCollect` on the specific Hook they wish to be called as a Weak TSH. + +### Fee Responsibility Table + +| Type of Weak Execution | Fee | +| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +|

Again As Weak
- Happens when a Strongly Executed Hook calls hook_again

| Free (already paid by the Strong Execution). | +|

Callback
- Happens when an emitted transaction either makes it into a ledger or is flagged as being impossible to ever make it into a ledger.

| Free (already paid during Emission). | +|

Weak Transactional Stakeholder
- Happens if a transaction in some way mildly affects your account.

| Paid for by your account (not by the originating transaction) if and only if both your account is marked with `asfTshCollect` flag and your Hook is marked with the `hsfCollect` flag. | + + diff --git a/src/content/docs/br/docs/hooks/concepts/compiling-hooks.mdx b/src/content/docs/br/docs/hooks/concepts/compiling-hooks.mdx new file mode 100644 index 0000000..4dc70e6 --- /dev/null +++ b/src/content/docs/br/docs/hooks/concepts/compiling-hooks.mdx @@ -0,0 +1,228 @@ +--- +title: Compiling Hooks +--- +import { Aside } from '@astrojs/starlight/components'; + +### Constraints + +All Hooks are compiled to a single [webassembly module](https://webassembly.github.io/spec/core/syntax/modules.html) before they can be set onto an Xahau account. + +A Hook always implements and exports exactly one or both of the following functions: + +`int64_t hook(uint32_t ctx) { ... }` _required_ + +* Executed whenever a transaction comes into or leaves from the account the Hook is set on (`ctx = 0`) or +* Executed when executed as a [Weak Transactional Stakeholder](/docs/hooks/concepts/weak-and-strong) (`ctx > 0`). + +`int64_t cbak(uint32_t ctx) { ... }` _optional_ + +* Executed when an emitted transaction is successfully accepted into a ledger (`ctx = 0`) or +* Executed when an emitted transaction cannot be accepted into any ledger (`ctx = 1`). + +Hooks are not allowed to specify other functions. Instead they must make clever use of macros to do all their computation within these two functions. This is part of a computational restriction on hooks to keep their runtime predictable. + +Additionally Hooks are afforded no _heap_ memory. All required memory must be reserved and used on the stack. + +### Example + +Here is an example Hook written in C. The Hook prints 0...3 to the trace log before accepting the originating transaction. + +```c +#include +#define GUARD(maxiter) _g(__LINE__, (maxiter)+1) +extern int32_t _g (uint32_t id, uint32_t maxiter); +extern int64_t accept (uint32_t read_ptr, uint32_t read_len, int64_t error_code); +extern int64_t trace_num (uint32_t read_ptr, uint32_t read_len, int64_t number); + +int64_t hook(uint32_t ctx) +{ + for (int i = 0; GUARD(3), i < 3; ++i) + { + trace_num("test", 4, i); + } + accept (0,0,0); + return 0; +} +``` + + + +### Compilation + +A [variety of compilers](https://www.google.com/search?q=webassembly+compiler+C) will generate valid webassembly from a C source file. Once compiled, a Hook exists as a binary `.wasm` file. This contains a webassembly module. Using `wasmcc` to compile and the `wasm2wat` tool to convert to human readable webassembly this binary form can be rendered to the human readable form. Below appears the compilation result of the above example. + +``` +(module + (type (;0;) (func (param i32 i32) (result i32))) + (type (;1;) (func (param i32 i32 i64) (result i64))) + (type (;2;) (func)) + (type (;3;) (func (param i32) (result i64))) + (import "env" "_g" (func $_g (type 0))) + (import "env" "trace_num" (func $trace_num (type 1))) + (import "env" "accept" (func $accept (type 1))) + (func $__wasm_call_ctors (type 2)) + (func $cbak (type 3) (param i32) (result i64) + (local i32 i32 i32 i64) + global.get 0 + local.set 1 + i32.const 16 + local.set 2 + local.get 1 + local.get 2 + i32.sub + local.set 3 + i64.const 0 + local.set 4 + local.get 3 + local.get 0 + i64.store offset=8 + local.get 4 + return) + (func $hook (type 3) (param i32) (result i64) + (local i32 i32 i32 i32 i32 i32 i32 i32 i32 i32 i32 i32 i32 i32 i32 i32 i32 i64 i32 i32 i32 i64 i32 i32 i32) + global.get 0 + local.set 1 + i32.const 16 + local.set 2 + local.get 1 + local.get 2 + i32.sub + local.set 3 + local.get 3 + global.set 0 + i32.const 0 + local.set 4 + local.get 3 + local.get 0 + i64.store offset=8 + local.get 3 + local.get 4 + i32.store offset=4 + block ;; label = @1 + loop ;; label = @2 + i32.const 3 + local.set 5 + i32.const 14 + local.set 6 + i32.const 4 + local.set 7 + local.get 6 + local.get 7 + call $_g + drop + local.get 3 + i32.load offset=4 + local.set 8 + local.get 8 + local.set 9 + local.get 5 + local.set 10 + local.get 9 + local.get 10 + i32.lt_s + local.set 11 + i32.const 1 + local.set 12 + local.get 11 + local.get 12 + i32.and + local.set 13 + local.get 13 + i32.eqz + br_if 1 (;@1;) + i32.const 1024 + local.set 14 + i32.const 4 + local.set 15 + local.get 3 + i32.load offset=4 + local.set 16 + local.get 16 + local.set 17 + local.get 17 + i64.extend_i32_s + local.set 18 + local.get 14 + local.get 15 + local.get 18 + call $trace_num + drop + local.get 3 + i32.load offset=4 + local.set 19 + i32.const 1 + local.set 20 + local.get 19 + local.get 20 + i32.add + local.set 21 + local.get 3 + local.get 21 + i32.store offset=4 + br 0 (;@2;) + end + end + i64.const 0 + local.set 22 + i32.const 0 + local.set 23 + local.get 23 + local.get 23 + local.get 22 + call $accept + drop + i32.const 16 + local.set 24 + local.get 3 + local.get 24 + i32.add + local.set 25 + local.get 25 + global.set 0 + local.get 22 + return) + (table (;0;) 1 1 funcref) + (memory (;0;) 2) + (global (;0;) (mut i32) (i32.const 66576)) + (global (;1;) i32 (i32.const 1029)) + (global (;2;) i32 (i32.const 1024)) + (global (;3;) i32 (i32.const 66576)) + (global (;4;) i32 (i32.const 1024)) + (export "memory" (memory 0)) + (export "__wasm_call_ctors" (func $__wasm_call_ctors)) + (export "__data_end" (global 1)) + (export "__global_base" (global 2)) + (export "__heap_base" (global 3)) + (export "__dso_handle" (global 4)) + (export "cbak" (func $cbak)) + (export "hook" (func $hook)) + (data (;0;) (i32.const 1024) "test\00")) +``` + +The average Hook developer will never need to examine webassembly directly. However it is a useful conceptual exercise to review the contents of the sample Hook. + +Above we can see: + +* Three functions are imported from the Hooks API (`_g`, `accept`, `trace_num`) +* Two functions are defined by the hook (`cbak`, `hook`) +* Two functions are exported by the hook (again: `cbak`, `hook`) +* Some static (constant) data is recorded in the hook (see `data` at the bottom). + +It is very important to note that a Hook _must only_ import functions available to it from the Hooks API and _must_ only export the `cbak` and `hook` functions. In additional all hooks must import `_g` from the Hooks API, which is the `guard` function. + + + +### Unwanted Exports + +Most webassembly compilers (including the one above) produce additional exports for their own linking purposes. In many cases the generation of these is difficult or impossible to disable. + +Unwanted exports will lead to an otherwise valid Hook being rejected. Therefore after compilation developers should use the [Hook Cleaner Utility](https://github.com/XRPLF/hook-cleaner-c) to strip out these out. Failure to do so will lead to your Hook being rejected. + + + diff --git a/src/content/docs/br/docs/hooks/concepts/debugging-hooks.mdx b/src/content/docs/br/docs/hooks/concepts/debugging-hooks.mdx new file mode 100644 index 0000000..e46b043 --- /dev/null +++ b/src/content/docs/br/docs/hooks/concepts/debugging-hooks.mdx @@ -0,0 +1,70 @@ +--- +title: Debugging Hooks +description: How to print "hello world" from your Hook! +--- +import { Aside } from '@astrojs/starlight/components'; + +### How can I debug a Hook? + +The Hook API provides a set of functions in the namespace `trace` which write output to the `xrpld` log file when xrpld is configured with the _trace_ log-level. These functions, generally speaking, allow you to see the value of variables, buffers and otherwise trace the execution and state of a Hook at runtime. + + + +### Trace APIs + +The following `trace` functions are available in the Hooks API + +| Hook API | What it does | +| ----------------------------------------------------------------------- | ----------------------------------------------------------------------------------------- | +| [trace](/docs/hooks/functions/trace-debug/trace) | Print a utf-8 message, followed by a user-specified buffer (this last optionally as hex.) | +| [trace_num](/docs/hooks/functions/trace-debug/trace_num) | Print a utf-8 message, followed by an integer. | +| [trace_float](/docs/hooks/functions/trace-debug/trace_float) | Print a utf-8 message, followed by an XFL Floating point number. | + +### Example + +The following code will print a single trace line then accept the Originating Transaction. + +```c +#include "../hookapi.h" +int64_t hook(int64_t reserved) +{ + trace_num(SBUF("A number"), 10); + accept(0,0,0); + return 0; +} +``` + +An example of the log-line produced by `xahaud` when a payment is sent out of or into the Hook Account: + +``` +2021-Apr-13 13:59:11.083700726 UTC View:TRC + HookTrace[rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh-rE3SfnjwfzZFL3JK9cLVfJuy8Ar1XnCqPw]: + A number 10 +``` + +The above appears in the log as all-one-line, but split here for visibility. + + + +### Log format + +A breakdown of the log format appears in the table below + +| Part | Description | # | +| ------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- | - | +| 2021-Apr-13 13:59:11.083700726 UTC View:TRC | `xahaud`'s prefix to the log line | 1 | +| HookTrace | This is a trace initiated by the Hook itself not some other information about the Hook. Other information is available on tags `HookError`, `HookEmit` and `HookInfo`. | 2 | +| \[rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh | The first account in the square brackets is the Hook Account. | 3 | +| -rE3SfnjwfzZFL3JK9cLVfJuy8Ar1XnCqPw]: | The second account in the square brackets is the Originating Account. | 4 | +| A number | This is the message the Hook was told to deliver before the trace payload | 5 | +| 10 | This is the trace payload | 6 | + + diff --git a/src/content/docs/br/docs/hooks/concepts/emitted-transactions.mdx b/src/content/docs/br/docs/hooks/concepts/emitted-transactions.mdx new file mode 100644 index 0000000..346d130 --- /dev/null +++ b/src/content/docs/br/docs/hooks/concepts/emitted-transactions.mdx @@ -0,0 +1,64 @@ +--- +title: Emitted Transactions +description: Your Hook can do a lot more than just block or allow transactions! +--- +import { Aside } from '@astrojs/starlight/components'; + +### Background + +**All** changes made to Xahau _must_ be the result of applying a valid transaction to the ledger. Thus if some change _X_ is made then some transaction _Y_ is responsible. + +When designing the Hooks API we needed a way for Hooks to make changes to the ledger _beyond_ simply accepting or rejecting a transaction. However attaching these changes to the Originating Transaction was confusing and resulted in a large increase in the general complexity of the system. + +Suppose for example that a Hook needs to send you some funds... the send operation would be effectively enacted onto the ledger by the Originating Transaction which might have been something completely unrelated such as an Account Set transaction. Additionally this send operation would need to be able to potentially trigger another Hook on the receiving end of a payment. + +The solution: **Emitted Transactions**. We allow the Originating Transaction to do exactly what the contents of the Transaction say it will do. If our Hook needs to make an additional change to the ledger such as sending a payment, it creates and then _emits_ a brand new transaction. + +### What are Emitted Transactions? + +Emitted Transactions are _new_ transactions created by the execution of a Hook and entered into consensus for processing in the next ledger. The transaction may be of any Transaction Type but must follow strict emission rules. + +To emit a transaction the Hook first prepares the serialized transaction then calls [emit](/docs/hooks/functions/emitted-transaction/emit-1). + +Because emitted transactions can trigger Hooks in the next ledger which in turn may emit more transactions, all emitted transactions carry a `burden` and a `generation` field in their `EmitDetails` block. The `EmitDetails` block replaces the signature field in a traditional transaction. + +The `burden` and `generation` fields collectively prevent [Fork bomb](https://en.wikipedia.org/wiki/Fork_bomb) attacks on the ledger by exponentially increasing the cost of exponentially expanding emtited transactions. + +It is important to note that the Hooks API follows the strict rule of _no rewriting_. You _must_ present an emitted transaction in full, valid and canonically formed to xahaud for emission or it will be rejected. It is not xahaud's job to build your transaction for you. The Hook must do this itself. + +### Callbacks + +As introduced in [Introduction and Terminology](/docs/hooks/concepts/terminology) emitted transactions trigger callbacks when they are accepted into a ledger. Due to the decentralised nature of consensus acceptance into a ledger of an emitted transaction is **not a guarantee**, although it is usually all-but guaranteed. + +If an emitted transaction expires before it can be accepted into a ledger (for any number of reasons: the ledgers may be full, the fee may be too high for the emitted transaction or the emitted transaction may be somehow invalid) then a _pseudo transaction_ is created in the ledger to clean up the emitted transaction. This pseudo transaction also calls the callback of your hook, with `parameter = 1` to indicate the emitted transaction indeed failed. + +### Emission Rules + +The [emit](/docs/hooks/functions/emitted-transaction/emit-1) Hook API will enforce the following rules on a proposed (to be emitted) transaction. + +| # | Emission Rule | Explanation | +| - | ------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| 1 | `sfSequence` = 0 | Emitted Transactions _do not_ increase the sequence number of the Hook Account. This must always be set to zero. | +| 2 | `sfPubSigningKey` = 0 | Emitted Transactions are not signed but this is a required field for xrpld processing. It must be set to all zeros. | +| 3 | `sfEmitDetails` present and valid | Emitted Transactions require an `sfEmitDetails` block and this must be correctly filled. See EmitDetails section below. | +| 4 | `sfSignature` absent | This field must be absent in the emitted transaction because if it were not then the transaction would be ambiguous. | +| 5 | `LastLedgerSequence` valid and in the future | All emitted transactions must have a last ledger sequence set so that the Hook knows if the emitted transaction failed (since it did not get a callback in time). This is currently set to a maximum of 5 ledgers after the current ledger. | +| 6 | `FirstLedgerSequence` valid and set to the next ledger | All emitted transactions must have a first ledger sequence set to the next ledger (after the current ledger) so that Hooks do not recursively cascade within a single ledger. This is currently enforced to be the next ledger after the current ledger. | +| 7 | Fee appropirately computed and set | The fee is dependent on the size of the emtited transaction and the burden on the network (i.e. whether this emitted transaction was the result of another emitted transaction.) | +| 8 | Generation cap not exceeded | An emitted transaction can produce other emitted transactions, and these can form a chain. The length of the chain is the `sfEmitGeneration`. This is currently capped at 10. | + +### EmitDetails block + +All emitted transactions must contain an `sfEmitDetails` object correctly populated with the fields in the table below. + +| Field | Required Value | Description | +| ----------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| sfEmitGeneration |

If the Originating Transaction was itself an emitted transaction then one more than the sfEmitGeneration of that transaction.

If the Originating Transaction was not an emitted transaction then 1.

This should be populated using etxn_generation.

| This field keeps track of a chain of emitted transactions that in turn cause other transactions to be emitted. | +| sfEmitBurden |

If the Originating Transaction was itself an emitted transaction then the burden of the Originating Transaction multiplied by the maximum number of transactions the Hook has declared it will emit using etxn_reserve.

If the Originating Transaction was not an emitted transaction then 1.

This should be populated using etxn_burden.

| 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. | +| sfEmitParentTxnID | The transaction ID of the Originating Transaction | 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. | +| sfEmitNonce | A special deterministic nonce produced by a call to [nonce](/docs/hooks/functions/emitted-transaction/etxn_nonce) | 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. | +| sfEmitCallback | The 20 byte Hook Account ID | This field is used by xahaud 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. | + + \ No newline at end of file diff --git a/src/content/docs/br/docs/hooks/concepts/execution-metadata.mdx b/src/content/docs/br/docs/hooks/concepts/execution-metadata.mdx new file mode 100644 index 0000000..fdc2a68 --- /dev/null +++ b/src/content/docs/br/docs/hooks/concepts/execution-metadata.mdx @@ -0,0 +1,20 @@ +--- +title: Execution Metadata +description: What to expect when your Hook runs. +--- + +When Hooks execute they leave behind information about the status of that execution. This appears in the Originating Transaction metadata as an `sfHookExecutions` block. This block contains the following fields: + + + +| Field | Description | +| ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| sfHookResult |

Hooks can end in three ways: accept, rollback and error.
This is not the same as sfHookReturnCode!

| +| sfHookHash | The SHA512H of the Hook at the time it was executed. | +| sfHookAccount | The account the Hook ran on. | +| sfHookReturnCode | The integer returned as the third parameter of `accept` or `rollback`. | +| sfHookReturnString | The string returned in the first two parameters of `accept` or `rollback`, if any. | +| sfHookInstructionCount | The total number of webassembly instructions that were executed when the Hook ran. | +| sfHookEmitCount | The total number of [Emitted Transactions](/docs/hooks/concepts/emitted-transactions) produced by the Hook. | +| sfHookExecutionIndex | The order in which the Hook was executed (as distinct from other Hook Executions on the same Originating Transaction.) | +| sfHookStateChangeCount | The number of [Hook State](/docs/hooks/concepts/state-management) changes the Hook made during execution. | diff --git a/src/content/docs/br/docs/hooks/concepts/floating-point-numbers-xfl.mdx b/src/content/docs/br/docs/hooks/concepts/floating-point-numbers-xfl.mdx new file mode 100644 index 0000000..794d3b1 --- /dev/null +++ b/src/content/docs/br/docs/hooks/concepts/floating-point-numbers-xfl.mdx @@ -0,0 +1,97 @@ +--- +title: Floating Point Numbers (XFL) +description: High precision calculations are native to Hooks. +--- +import { Aside } from '@astrojs/starlight/components'; + +### Background + +[Floating point numbers](https://en.wikipedia.org/wiki/Floating-point_arithmetic) are widely used in computer science to do calculation of finite precision but arbitrary scale numbers. + +Most modern CPUs are capable of performing fast floating point operations using the [IEEE binary floating point standard](https://en.wikipedia.org/wiki/Double-precision_floating-point_format) however `xahaud` does **not** use this format. Instead Xahau uses a [bespoke decimal floating point standard](/docs/protocol-reference/binary-format). + +This custom format has three basic properties: + +1. The format is inherently decimal, expressed as a decimal `mantissa` multipled by `10` to the power of an `exponent`. +2. All values expressed have 16 significant (decimal) figures. +3. The range of exponents is `-96` to `+80` + +When serialized the mantissa is 54 bits, and the exponent is 8 bits, with a final sign bit bringing the total size of the serialized floating point to 63 bits. + +### What is XFL? + +[XLS-17d](https://github.com/XRPLF/XRPL-Standards/discussions/39) is an XRPL standards proposal that defines an efficient way to pack and store xrpld floating point numbers (as described above). + +XFLs store the bits of the floating point number within an _enclosing number_. This is always an `int64_t`. Negative enclosing numbers represent invalid XFLs (for example as a result of division by zero.) + + + +Some example XFLs follow + +| loating Point Value | Enclosing Number | Representation | +| ------------------- | ------------------- | ----------------------------- | +| -1 | 1478180677777522688 | -1000000000000000 \* 10^(-15) | +| 0 | 0 | 0 (_canonical zero_) | +| 1 | 6089866696204910592 | +1000000000000000 \* 10^(-15) | +| _PI_ | 6092008288858500385 | +3141592653589793 \* 10^(-15) | +| -_PI_ | 1480322270431112481 | -3141592653589793 \* 10^(-15) | + +This format is very convenient for Hooks, as Hooks can only exchange _integer_ values with xrpld. By enclosing the floating point inside an integer in a well defined way it becomes possible to do complex floating point computations from a Hook. This is useful for computing exchange rates. + +### Canonical Zero + +Floating point regimes typically have a number of different ways to express zero, which can be a problem for testing for zero. For example `0 x 10 ^ 1` is zero and `0 x 10 ^ 2` is also zero. For this reason there is a canonical zero enforced by the standard and the Hook API. The canonical zero is also enclosing number zero (`0`). + +### Hook Float API + +Once you have an XFL you can use the Float API to do various computations. The Float API appears in the table below. Each API takes one or more XFL enclosing numbers and returns an XFL enclosing number. Negative return values _always_ represent a computational error (such as division by zero). There are no valid negative enclosing numbers. + +| Hook API | What it does | +| ----------------------------------------------------------------------- | --------------------------------------------------------------------- | +| [float_set](/docs/hooks/functions/float/float_set) | Create a float from an exponent and mantissa | +| [float_multiply](/docs/hooks/functions/float/float_multiply) | Multiply two XFL numbers together | +| [float_mulratio](/docs/hooks/functions/float/float_mulratio) | Multiply an XFL floating point by a non-XFL numerator and denominator | +| [float_negate](/docs/hooks/functions/float/float_negate) | Negate an XFL floating point number | +| [float_compare](/docs/hooks/functions/float/float_compare) | Perform a comparison on two XFL floating point numbers | +| [float_sum](/docs/hooks/functions/float/float_sum) | Add two XFL numbers together | +| [float_sto](/docs/hooks/functions/float/float_sto) | Output an XFL as a serialized object | +| [float_sto_set](/docs/hooks/functions/float/float_sto_set) | Read a serialized amount into an XFL | +| [float_invert](/docs/hooks/functions/float/float_invert) | Divide one by an XFL floating point number | +| [float_divide](/docs/hooks/functions/float/float_divide) | Divide an XFL by another XFL floating point number | +| [float_one](/docs/hooks/functions/float/float_one) | Return the number 1 represented in an XFL enclosing number | +| [float_exponent](/docs/hooks/functions/float/float_exponent) | Get the exponent of an XFL enclosing number | +| [float_mantissa](/docs/hooks/functions/float/float_mantissa) | Get the mantissa of an XFL enclosing number | +| [float_sign](/docs/hooks/functions/float/float_sign) | Get the sign of an XFL enclosing number | +| float_exponent_set | Set the exponent of an XFL enclosing number | +| float_mantissa_set | Set the mantissa of an XFL enclosing number | +| float_sign_set | Set the sign of an XFL enclosing number | +| [float_int](/docs/hooks/functions/float/float_int) | Convert an XFL floating point into an integer floor | +| [float_root](/docs/hooks/functions/float/float_root) | Compute the nth root of an XFL | +| [float_log](/docs/hooks/functions/float/float_log) | Compute the decimal log of an XFL | + + + +### Example + +In the below example an exchange rate conversion is performed, followed by a high precision fraction multiplication. + +```c +int64_t max_vault_pusd = + float_multiply(vault_xrp, exchange_rate); + +max_vault_pusd = + float_mulratio(max_vault_pusd, 0, + NEW_COLLATERALIZATION_NUMERATOR, NEW_COLLATERALIZATION_DENOMINATOR); +``` + + diff --git a/src/content/docs/br/docs/hooks/concepts/grants.mdx b/src/content/docs/br/docs/hooks/concepts/grants.mdx new file mode 100644 index 0000000..9352f2c --- /dev/null +++ b/src/content/docs/br/docs/hooks/concepts/grants.mdx @@ -0,0 +1,90 @@ +--- +title: Grants +description: Hook Grants +--- +import { Aside } from '@astrojs/starlight/components'; + + + +### Grants + +Grants provide a way for a Hook Installer to assign [State Management](/docs/hooks/concepts/state-management) permissions to a _foreign_ Hook on other Xahau accounts. + +A [SetHook Transaction](/docs/hooks/concepts/sethook-transaction) may specify a `HookGrants` array within any `Hook` object in its `Hooks` array. The `HookGrants` array contains one or more `HookGrant` objects (up to 8). + +Unlike [Parameters](/docs/hooks/concepts/parameters), the `HookGrants` array is always set exactly as specified in the [SetHook Transaction](/docs/hooks/concepts/sethook-transaction). Therefore if you wish to update a particular `HookGrant` whilst retaining multiple other `HookGrant` entires that were previously set, you must first obtain the old `HookGrants` array, modify it, and then resubmit the entire array in an [_Update_ Operation](/docs/hooks/concepts/sethook-transaction). + +To delete all Grants submit an empty `HookGrants` array. + + + +A Grant permits a foreign XRPL account or Hook to modify the Hook State within the namespace of the specific Hook for which the Grant is defined. + +The HookGrant must specify at least: + +* `HookHash`\ + And may also specify an account: +* `Authorize` + +Only the Hook specified by HookHash may modify the Hook State within the namespace of the Hook for which the HookGrant is specified. If `Authorize` is specified then this permission is tightened further to only the Hook specified by the HookHash when it is installed on the account specified by `Authorize`. + + + +### Example + +```json +Account: "rALicebv3hMYNBWtu1VEEWkToArgYsYERs", +TransactionType: "SetHook", +Hooks: +[ + { + Hook: { + ..., + HookNamespace: "3963ADEB1B0E8934C0963680531202FD511FF1E16D5864402C2DA63861C420A8", + HookGrants: + [ + { + HookGrant: // first grant + { + HookHash: "78CAF69EEE950A6C55A450AC2A980DE434D624CD1B13148E007E28B7B6461CC8" + }, + HookGrant: // second grant + { + Authorize: "rCLairev2ma2gNZdcHJeTk7fCQ1ki84vr9", + HookHash: "A5B8D62154DA1C329BE13582086B52612476720CEBD097EB85CEE1455E1C70A6" + } + }, + ] + } + } +], +... +``` + +The _first grant_ above allows: + +* any instance of the Hook whose code that hashes to `78CAF69EEE950A6C55A450AC2A980DE434D624CD1B13148E007E28B7B6461CC8` +* executing on **any account** +* to modify the Hook State of account `rALicebv3hMYNBWtu1VEEWkToArgYsYERs` +* inside the Namespace `3963ADEB1B0E8934C0963680531202FD511FF1E16D5864402C2DA63861C420A8` + +The _second grant_ above allows: + +* any instance of the Hook whose code that hashes to `A5B8D62154DA1C329BE13582086B52612476720CEBD097EB85CEE1455E1C70A6` +* but only when executed on account `rCLairev2ma2gNZdcHJeTk7fCQ1ki84vr9` +* to modify the Hook State of account `rALicebv3hMYNBWtu1VEEWkToArgYsYERs` +* inside the Namespace `3963ADEB1B0E8934C0963680531202FD511FF1E16D5864402C2DA63861C420A8` + +### Using the Grant + +To make use of a grant, a Hook modifies State objects on a foreign account by calling [state_foreign_set](/docs/hooks/functions/state/state_foreign_set). diff --git a/src/content/docs/br/docs/hooks/concepts/hook-fees.mdx b/src/content/docs/br/docs/hooks/concepts/hook-fees.mdx new file mode 100644 index 0000000..3bced10 --- /dev/null +++ b/src/content/docs/br/docs/hooks/concepts/hook-fees.mdx @@ -0,0 +1,64 @@ +--- +title: Hook Fees +description: What to expect when your Hook runs. +--- +### Hook Creation Fees + +SetHook transactions are charged per byte of created webassembly. The rate is 500 drops per byte. Thus a 1kib Hook will cost 0.5 XAH to create. + +### Hook Execution Fees + +When Hooks are [Strongly Executed](/docs/hooks/concepts/weak-and-strong) the originating transaction must pay for the Strong Executions in the originating transaction's fee. + +Hook Execution fees are charged at a rate of 1 drop per web assembly instruction in the worst-case execution of the function `hook` (or `cbak` in the case of a callback). Thus a small Hook with a lot of looping may end up attracting high runtime fees. + +### Fee RPC Helper + +Transaction fees on a ledger with the Hooks Amendment enabled become non-trivial to compute for end-users and/or wallet applications. This is because strong hooks must be paid for by the originator of a transaction, and there may be as many as 4 strong hooks on the sending account and 4 on the receiving account, as well as any other strong transactional stakeholders involved (as can be the case with some exotic transaction types). Further, if the transaction is a SetHook then the size of the parameters, the size of the code and whether it is a _create_ operation or an _install_ operation all determine the size of the fee. + +Therefore it is highly recommended that **all** transactions be run through the updated fee RPC call before they are submitted to the ledger. + +To invoke the RPC call: + +1. Open a websocket connection to the Hooks node you will be working with. +2. Compose the serialized transaction you wish to know the fee for with the following: + +* `Fee: "0"` +* `SigningPubKey: ""` (That is: 0 byte VL of type 0x73. In hex:`0x7300`.) +* Do **not** sign the transaction. + +3. Submit it as a hex blob to the RPC as follows: + +```json +{"command":"fee", "tx_blob":""} +``` + +For HTTP POST RPC submit it as follows: + +```json +{"method":"fee", "params": [{"tx_blob":""}] } +``` + +The response should look something like + +```json +{ + result: { + drops: { + base_fee: '130520', + }, + //... + }, + type: 'response' +} +``` + +Take the base fee and set it as the `Fee` field in the transaction. Now sign and submit it as per the normal transaction submission process. + +If there is an invalid value for `tx_blob` or `tx_blob` is missing, a regular JSON result will be returned with a `base_fee` of 10. + +### Emission Fees + +Hooks have access to the same computation the _Fee RPC Helper_ does. To use this simply call [etxn_fee_base](/docs/hooks/functions/emitted-transaction/etxn_fee_base) with a buffer containing the serialised transaction as the arguments. As with the RPC call, you must ensure that the `Fee` field is present in the serialised transaction. The value is irrelevant. + +When `etxn_fee_base` returns the recommended fee you may use [sto_emplace](/docs/hooks/functions/serialization/sto_emplace) to emplace it into the serialised transaction before emission. The relevant field is `sfFee`. diff --git a/src/content/docs/br/docs/hooks/concepts/hookon-field.mdx b/src/content/docs/br/docs/hooks/concepts/hookon-field.mdx new file mode 100644 index 0000000..eca806e --- /dev/null +++ b/src/content/docs/br/docs/hooks/concepts/hookon-field.mdx @@ -0,0 +1,44 @@ +--- +title: HookOn Field +description: Specify which transaction types a Hook should be triggered on +--- +import { LinkCard } from '@astrojs/starlight/components'; + +### Understanding the HookOn field + +Each bit in this unsigned 256-bit integer indicates whether the Hook should execute on a particular transaction type. All bits are _active low_ **except** bit 22 which is _active high_. Since 22 is ttHOOK_SET this means the default value of all 0's will not fire on a SetHook transaction but will fire on every other transaction type. This is a deliberate design choice to help people avoid bricking their Xahau account with a misbehaving hook. + +Bits are numbered from right to left: + +* bit 0 - right most, i.e. the least significant bit. +* bit 63 - the left-most, i.e. the most significant bit. + +Examples (assuming a 256-bit unsigned integer type): + +1. If we want to completely disable the hook: + +```c +~(1ULL << 22) /* every bit is 1 except bit 22 which is 0 */ +``` + +2. If we want to disable the hook on everything except ttPAYMENT: + +```c +~(1ULL << 22) & ~(1ULL) +``` + +3. If we want to enable the hook on everything except ttHOOK_SET + +```c +0 +``` + +4. If we want to enable hook firing on ttHOOK_SET (dangerous) and every other transaction type: + +```c +(1ULL << 22) +``` + +### HookOn Calculator + + diff --git a/src/content/docs/br/docs/hooks/concepts/introduction/example-usage.mdx b/src/content/docs/br/docs/hooks/concepts/introduction/example-usage.mdx new file mode 100644 index 0000000..b1f60a0 --- /dev/null +++ b/src/content/docs/br/docs/hooks/concepts/introduction/example-usage.mdx @@ -0,0 +1,24 @@ +--- +title: Example Usage +--- +Please read [the introduction of Hooks in this blog](https://coil.com/p/XUMM/XRPL-Labs-is-working-on-the-transaction-HOOKS-amendment-for-the-XRP-Ledger-Supporting-business-logic/kEmqhoqMW). + +While working on Hooks we published a number of blogs on our progress, insights & Hooks concepts. You can [read all about that in our blogs on Dev.to](https://dev.to/t/xrplhooks/top/infinity) + +### Examples (scenarios) + +#### 1. Receiving Hook executes additional logic + +![senarios-1](/assets/hook-examples-senarios-1.png) + +#### 2. Receiving Hook blocks incoming transaction + +![senarios-2](/assets/hook-examples-senarios-2.png) + +#### 3. Sending Hook blocks outgoing transaction + +![senarios-3](/assets/hook-examples-senarios-3.png) + +#### 4. Hook controls an institutional account + +![senarios-4](/assets/hook-examples-senarios-4.png) diff --git a/src/content/docs/br/docs/hooks/concepts/introduction/index.mdx b/src/content/docs/br/docs/hooks/concepts/introduction/index.mdx new file mode 100644 index 0000000..f74714d --- /dev/null +++ b/src/content/docs/br/docs/hooks/concepts/introduction/index.mdx @@ -0,0 +1,33 @@ +--- +title: Introduction +--- + +import { Aside } from '@astrojs/starlight/components'; + +Hooks add smart contract functionality to the Xahau: _layer one_ custom code to influence the behaviour and flow of transactions. Hooks are small, efficient pieces of code being defined on an Xahau account, allowing logic to be executed before and/or after Xahau transactions. + + + +Xahau is known and is being appreciated for its transaction throughput, speed and the low fees. Combined with available advanced transaction types like multi sign, escrows, payment channels and even a decentralized exchange (all on ledger, out of the box, without requiring smart contracts) Xahau has a lot to offer businesses and creative developers. + +Hooks add smart contract functionality to Xahau: _layer one_ custom code to influence the behaviour and flow of transactions. Hooks are small, efficient pieces of code being defined on an Xahau account, allowing logic to be executed before and/or after Xahau transactions. These Hooks can be really simple, like: “reject payments < 10 XAH”, or “for all outgoing payments, send 10% to my savings account” or more advanced. + +
+![Hooks high level concept](/assets/spaces_m6f29os4wP16vCS4lHNh_uploads_sEBiInWuRskTqxB29Xgd_7359187-Hooks_High_Level2x_1.png) +
*Hooks high level concept*
+
+ +By allowing Hooks to not only execute efficient logic but also to store small, simple data objects, one could define a Hook like: “for incoming payments transactions, check if the sending account is in a list maintained by another Hook, and if present: reject the transaction”. + +Hooks are deliberately not Turing-Complete. While often touted as the holy grail of smart contracts, Turing-Completeness is actually inappropriate for smart contracts. (See [Blog 2](https://dev.to/wietse/hooked-2-hooks-security-smart-contracts-on-the-xrp-ledger-83e).) + +Hooks are currently live on a public testnet. It's time for testing, coding, having fun & breaking things, so a future amendment to add Hooks to Xahau livenet can be drafted with confidence. + +### Resources + +* [Xahau Testnet](https://xahau-test.net/) +* [Xahau Testnet Explorer](https://explorer.xahau-test.net/) +* [Examples (source code)](https://github.com/XRPL-Labs/xrpld-hooks/tree/hooks-ssvm/hook-api-examples) +* [Blogs concepts](https://dev.to/t/xrplhooks/top/infinity) diff --git a/src/content/docs/br/docs/hooks/concepts/loops-and-guarding.mdx b/src/content/docs/br/docs/hooks/concepts/loops-and-guarding.mdx new file mode 100644 index 0000000..f4bc271 --- /dev/null +++ b/src/content/docs/br/docs/hooks/concepts/loops-and-guarding.mdx @@ -0,0 +1,90 @@ +--- +title: Loops and Guarding +description: Guards are needed to perform loops in a Hook. +--- +import { Aside } from '@astrojs/starlight/components'; + +### What are guards? + +Hooks are deliberately not [Turing Complete](https://en.wikipedia.org/wiki/Turing_completeness). This means arbitrary looping is forbidden. Instead you must _guard_ your loops against a hard "maximum iteration" boundary. + +A guard is a marker placed in your code at the top of each loop. The marker informs the Xahau what the upper bound of your loop will be _in every possible scenario_. Thus if your loop usually executes twice but sometimes executes _500_ times, then your guard will say 500. + +Guards are used by the Xahau to determine the _worst case execution time_ (in instructions) of your Hook before execution. This is the basis for the fee the Xahau charges for the execution of a Hook and makes execution times predictable and controllable. + + + +### The guard function + +The guard function tells the ledger the **maximum number of iterations** a loop will make. Specifically the function takes two arguments: + +```c +int32_t _g (uint32_t id, uint32_t maxiter); +``` + +The first argument `id` is the identifier for this guard. This is a unique constant chosen by the developer, typically the line number in the source file is used. + +The second argument `maxiter` is a promise the developer makes to the ledger that this guard will not be _hit_ more than `maxiter` times during the execution of the Hook. If the guard call is executed more than this many times the Hook will automatically rollback with a `GUARD_VIOLATION` ([Hook API return codes](/docs/hooks/functions/overview/return-codes)). Because the guard will be hit _before_ the loop condition is checked, it is important to add one to the total number of expected iterations. (Note: The GUARD() macro already adds one). + + + +### Guard enforcement + +Consider the following for-loop in C: + +```c +#define GUARD(maxiter) _g(__LINE__, (maxiter)+1) +for (int i = 0; GUARD(3), i < 3; ++i) +{ + ... +} +``` + +In C, the comma operator executes each expression in a list of expressions (e.g. `A, B, C`) and returns the last expression (e.g. `C`). Thus the condition above is still `i < 3`, but the guard is called before the condition is checked. This is the only way to satisify the _guard rule_ when using a for-loop in C. + + + +Below appears the webassembly output when the above is compiled. Note the guard function being called at the start of the loop. The only instructions allowed before this call are non-branch instructions (typically manipulating constants.) + +``` + block ;; label = @1 + loop ;; label = @2 + i32.const 3 + i32.const 14 +=====> call $_g <===== + drop + ... +``` + +### Nested Loops + +When using nested loops the `maxiter` argument must reflect the total number of times the guard will be _hit_. This means you must multiply the nestings together. + +Consider the example below: + +```c +#define GUARD(maxiter) _g(__LINE__, (maxiter)+1) +for (int i = 0; GUARD(3), i < 3; ++i) +{ + for (int j = 0; GUARD(15), j < 5; ++j) + { + ... + } +} +``` + +Notice the inner-loop's guard is set to **15**. You must multiply the loops together to compute the maximum number of times an inner guard will be hit during Hook execution. + +### No recursion + +Calls to non-Hook API functions are disallowed in the Hooks ammendment. All user code must fit within the two allowed Hook functions `cbak` and `hook`. + + diff --git a/src/content/docs/br/docs/hooks/concepts/namespaces.mdx b/src/content/docs/br/docs/hooks/concepts/namespaces.mdx new file mode 100644 index 0000000..441877b --- /dev/null +++ b/src/content/docs/br/docs/hooks/concepts/namespaces.mdx @@ -0,0 +1,41 @@ +--- +title: Namespaces +description: Prevent state clobbering by using the correct namespace +--- +### Namespaces + +To avoid two or more Hooks installed on the same account unintentionally clobbering each-other's [Hook State](/docs/hooks/concepts/state-management), a 32 byte namespace must be provided when creating or installing each Hook. + +The namespace may be any arbitrary 32 byte value the developer chooses. Provided the namespace is unique in the Hook chain no state clobbering will occur. + +We strongly recommended using `SHA256` over the developer's working name for the Hook. SHA256 is one of the two hashing algorithms used in the derivation of Xahau addresses (from an account master key), and, as such, it should be readily available to the developer. + +The `HookNamespace` field is supplied as a 32 byte _hex_ blob inside each `Hook` object in a `Hooks` array when [executing a SetHook transaction](/docs/hooks/concepts/sethook-transaction). + +The configured Namespace a Hook operates under alters the [Keylets](/docs/hooks/concepts/slots-and-keylets) its [State](/docs/hooks/concepts/state-management) is stored under. Therefore two Hooks under two different Namespaces installed on the same Xahau account may use the same state key to refer to different state objects. Conversely, two different Hooks using the same Namespace on the same Xahau account can access and modify eachother's state objects using the same state keys. + +### Example + +In javascript, importing the `ripple-address-codec` yields access to SHA256.\ +(It is also possible to use `crypto.subtle` in browser, or `crypto.createHash` in node to access this hash algorithm.) + +```js +HookNamespace: addr.codec.sha256('carbon').toString('hex') +``` + +### Default Namespace + +The first user to [set a novel Hook](/docs/hooks/concepts/sethook-transaction) defines a `HookNamespace` which becomes the _Default Namespace_ for that Hook. This means any subsequent users who [reference the same _HookDefinition_](/docs/hooks/concepts/reference-counted-hook-definitions) will receive this originally set Namespace by default. + +The subsequent user may specify their own Namespace, overriding the Default Namespace for their installation only. + +### Hook APIs Affected + +Choice of HookNamespace affects the behaviour of the following Hook APIs: + +* [state](/docs/hooks/functions/state/state) +* [state_set](/docs/hooks/functions/state/state_set) + +### Namespace API Helper + +See [account_info](/docs/hooks/functions/websocket-apis/account_info) and [account_namespace](/docs/hooks/functions/websocket-apis/account_namespace) for information about how to query the ledger regarding namespaces. diff --git a/src/content/docs/br/docs/hooks/concepts/parameters.mdx b/src/content/docs/br/docs/hooks/concepts/parameters.mdx new file mode 100644 index 0000000..d28c12b --- /dev/null +++ b/src/content/docs/br/docs/hooks/concepts/parameters.mdx @@ -0,0 +1,57 @@ +--- +title: Parameters +description: Install-time parameters allow Hooks to be generic and flexible +--- +### Parameters + +Hook developers may opt to use _install-time_ parameters (called Hook Parameters) in their Hook. This allows subsequent installers of the Hook to change certain behaviours the programmer defines without recompiling or re-uploading the Hook (assuming at least one account still [references](/docs/hooks/concepts/reference-counted-hook-definitions) the existing Hook Definition.) + +Hook Parameters are a set of Key-Value pairs set during the [SetHook Transaction](/docs/hooks/concepts/sethook-transaction) and retrievable by the Hook during runtime. Both the `ParameterName` key and the `ParameterValue` are set as _hex_ blobs, and have a maximum length of 32 bytes and 256 bytes respectively. + +A [SetHook Transaction](/docs/hooks/concepts/sethook-transaction) may define up to _16_ Hook Parameters per installed Hook. + +### Setting Parameters + +The `HookParameters` array is optionally defined inside each `Hook` in the `Hooks` array as shown below: + +```json +TransactionType: "SetHook", +Hooks: +[ + { + Hook: { + ..., + HookParameters: + [ + { + HookParameter: + { + HookParameterName: "ABCDEF12", + HookParameterValue: "12345678" + } + }, + ... // optionally up to 15 more Hook Parameters + ] + } + } +], +... +``` + +### Default Parameters + +The first user to [set a novel Hook](/docs/hooks/concepts/sethook-transaction) may define Hook Parameters which then become the _Default Parameters_ for that Hook. This means any subsequent users who [references the same _HookDefinition_](/docs/hooks/concepts/reference-counted-hook-definitions) will receive these originally set Hook Parameters by default. + +The subsequent user may specify their own Parameters, overriding the Default Parameters for their installation. + +To erase a Parameter in a subsequent installation, specify the `ParameterName` key without specifying a `ParameterValue` key. + +### Using Parameters in Hooks + +Parameters can be read by the Hooks they are set on using [hook_param](/docs/hooks/functions/hook-context/hook_param). + +If more than one Hook is installed in a Hook Chain, then [hook_param_set](/docs/hooks/functions/hook-context/hook_param_set) can be used in limited circumstances to modify the Hook Parameters of a Hook further down the chain on the same account. + +### Runtime Parameters + +On Xahau and the Xahau testnet, HookParameters may also be included at the top level of any transaction type according to the foregoing rules and size limits. These parameters can be accessed inside a hook using the [otxn_param](/docs/hooks/functions/originating-transaction/otxn_param) API. diff --git a/src/content/docs/br/docs/hooks/concepts/reference-counted-hook-definitions.mdx b/src/content/docs/br/docs/hooks/concepts/reference-counted-hook-definitions.mdx new file mode 100644 index 0000000..72942cf --- /dev/null +++ b/src/content/docs/br/docs/hooks/concepts/reference-counted-hook-definitions.mdx @@ -0,0 +1,14 @@ +--- +title: Reference Counted Hook Definitions +description: Avoid re-uploading the same bytecode to the ledger +--- +When a novel Hook's web assembly byte-code is uploaded to Xahau, a significant storage burden is imposed on the network. This storage burden is reflected in the [Hook Fees](/docs/hooks/concepts/hook-fees) charged by the network. + +To avoid this burden (and high fees for end users) reference counting is used: + +* The first time a novel Hook is installed, the [SetHook Transaction](/docs/hooks/concepts/sethook-transaction) must provide a significant fee. +* The Hook's web assembly byte-code becomes an unowned and reference counted object on the ledger (called a `HookDefinition`). +* Subsequent installations by the same or other users for an identical Hook (i.e. with identical byte-code) increment the reference count. These installations point at the same object on the ledger. These transactions are billed in a similar way to setting a Trust Line, as the storage burden for the Hook was already paid for in the original Set Hook transaction. +* While the reference count on the Hook Definition is greater than zero (meaning one or more accounts still have the Hook installed) the object remains on the ledger. + +![Reference Counted Hook Definitions](/assets/spaces_m6f29os4wP16vCS4lHNh_uploads_TlDL7tsVNYi1yU64EZQh_3ef0cee-sethook-Page-2.png) diff --git a/src/content/docs/br/docs/hooks/concepts/serialized-objects.mdx b/src/content/docs/br/docs/hooks/concepts/serialized-objects.mdx new file mode 100644 index 0000000..9c3df60 --- /dev/null +++ b/src/content/docs/br/docs/hooks/concepts/serialized-objects.mdx @@ -0,0 +1,54 @@ +--- +title: Serialized Objects +description: Manipulate raw serialized xahaud objects! +--- +### What are Serialized Objects? + +Xahau has canonical [serialized](/docs/protocol-reference/binary-format) forms of all objects subject to consensus. When writing a Hook it is inevitable you will come across serialized objects. These manifest as buffers containing what might appear to the developer as opaque binary blobs. In fact you can read these with the [XRPL-Binary-Visualiser](https://richardah.github.io/xrpl-binary-visualizer/). + +For example an `sfAmount` field serializes to a collection of bytes like `61D50F26109A32B7EC` + +### Serialized Object API + +To assist Hook developers in working with serialized objects the `sto` namespace was created within the Hooks API. These functions manipulate pointers within a Hook-provided buffer. See table below. + +| Hook API | at it does | +| --------------------------------------------------------------------------- | ------------------------------------------------------------------------------------- | +| [sto_subfield](/docs/hooks/functions/serialization/sto_subfield) | Index into a xrpld serialized object and return the location and length of a subfield | +| [sto_subarray](/docs/hooks/functions/serialization/sto_subarray) | Index into a xrpld serialized array and return the location and length of an index | +| [sto_emplace](/docs/hooks/functions/serialization/sto_emplace) | Emplace a field into an existing STObject at its canonical placement | +| [sto_erase](/docs/hooks/functions/serialization/sto_erase) | Remove a field from an STObject | +| [sto_validate](/docs/hooks/functions/serialization/sto_validate) | Validate an STObject | + +Where applicable these APIs return an _offset_ and a _length_ encoded into a single int64_t. See individual documentation for details. + +### Example + +At typical scenario in which you would use the STO API is in processing memos on an Originating Transaction. Since you will likely need access to the whole memo anyway, an efficient way to process a set of memos is simply to dump the whole `sfMemos` field into a buffer then index around within it. While it is also possible to use the slot API to do this by slotting the Originating Transaction it would result in additional code and additional copying. + +```c +#define SUB_OFFSET(x) ((int32_t)(x >> 32)) +#define SUB_LENGTH(x) ((int32_t)(x & 0xFFFFFFFFULL)) +#define SBUF(str) (uint32_t)(str), sizeof(str) + +uint8_t memos[2048]; +int64_t memos_len = otxn_field(SBUF(memos), sfMemos); +for (int i = 0; GUARD(3), i < 3; ++i) +{ + int64_t memo_lookup = sto_subarray(memos, memos_len, i); + if (memo_lookup < 0) + rollback(SBUF("Memo lookup error"), 1); + uint8_t* memo_ptr = SUB_OFFSET(memo_lookup) + memos; + uint32_t memo_len = SUB_LENGTH(memo_lookup); + // the above now point at the memo ... do something here +} +``` + +### Overlap with slots + +You may notice some overlap between slot APIs and STO APIs. The key difference here is who _owns_ the underlying data: + +* If you are using _slots_ then xrpld owns the object you are interacting with. +* If you are using the _STO API_ then the **Hook** owns the buffer you are interacting with. + +Both sets of functions index into a Serialized Object without unnecessary copying. diff --git a/src/content/docs/br/docs/hooks/concepts/sethook-transaction.mdx b/src/content/docs/br/docs/hooks/concepts/sethook-transaction.mdx new file mode 100644 index 0000000..c04f31e --- /dev/null +++ b/src/content/docs/br/docs/hooks/concepts/sethook-transaction.mdx @@ -0,0 +1,314 @@ +--- +title: SetHook Transaction +--- +### SetHook Transaction + +Hook web assembly bytecode is installed onto an Xahau account using the `SetHook` transaction. + +An example appears below: + +```js +{ + Account: "r4GDFMLGJUKMjNhhycgt2d5LXCdXzCYPoc", + TransactionType: "SetHook", + Fee: "2000000", + Hooks: + [ + { + Hook: { + CreateCode: fs.readFileSync('accept.wasm').toString('hex').toUpperCase(), + HookOn: '0000000000000000', + HookNamespace: addr.codec.sha256('accept').toString('hex').toUpperCase(), + HookApiVersion: 0 + } + } + ] +} +``` + +The transaction is deceptively simple, but hides significant complexity, described below. + +### Hooks Array + +The main body of the SetHook transaction is the hooks array: + +```js +{ + Account: "r4GDFMLGJUKMjNhhycgt2d5LXCdXzCYPoc", + TransactionType: "SetHook", + Hooks: // This is the Hooks Array + [ + { Hook: { ... } }, // HookSet Object (position 0) + { Hook: { ... } }, + { Hook: { ... } }, + { Hook: { ... } }. // HookSet Object (position 3) + ] +} +``` + +This array _mirrors_ the [Hook Chain](/docs/hooks/concepts/chaining) installed on the account: + +* Position 0 in the array _corresponds_ to position 0 in the Hook Chain. +* Position 3 in the array _corresponds_ to position 3 in the Hook Chain, etc. + +### HookSet Object and Corresponding Hook + +Each entry in the Hooks Array (in the SetHook Transaction) is called a _HookSet Object_, and its corresponding Hook in the account's Hook Chain is called the _Corresponding Hook_. + +
+![Example: A user performs an operation on each Hook in his/her Hook chain with a SetHook transaction.](/assets/spaces_m6f29os4wP16vCS4lHNh_uploads_NbV5W3McCRKkL4eJeF6v_cdf692e-sethook.png) +
*Example: A user performs an operation on each Hook in his/her Hook chain with a SetHook transaction.*
+
+ +### HookDefinition + +Each Corresponding Hook is an object containing a _reference_ (pointer) to a `HookDefinition` object. + +The HookDefinition object is an unowned reference-counted ledger object that provides for de-duplication of identical web assembly bytecode. Two users using an identical hook will both point to the same HookDefinition. + +
+![Example: Hook Definitions on Xahau](/assets/spaces_m6f29os4wP16vCS4lHNh_uploads_TlDL7tsVNYi1yU64EZQh_3ef0cee-sethook-Page-2.png) +
*Example: Hook Definitions on Xahau*
+
+ +For more information see: [Reference Counting](/docs/hooks/concepts/reference-counted-hook-definitions) + +### Hook Defaults + +When a `HookDefinition` is created it contains the initial [Parameters](/docs/hooks/concepts/parameters), [Namespace](/docs/hooks/concepts/namespaces) and [Grants](/docs/hooks/concepts/grants) supplied by the user. These become the Hook Defaults. Any Hook referencing this Hook Definition will use these defaults _unless_ the SetHook Transaction that creates that reference explicitly overrides those defaults, or a subsequent Update Operation overrides them. + +### HookSet Operations + +There are six possible operations: No Operation, Create, Update, Delete, Install and Namespace Delete + +Each operation is specified by the inclusion or omission of certain HookSet Object fields. This might seem confusing at first but by working through a few examples the reader should find it intuitive; Essentially HookSet operations are a type of **diff** between a specific Hook's _defaults_, _existing_ and newly specified fields. + +Achieving each type of operation is explained in a subsection below. + +### No Operation + +**Occurs when**: + +* The HookSet Object is empty + +**Behaviour**: + +* No change of any kind is made. + +**Example**: + +```json +{ + Account: "r4GDFMLGJUKMjNhhycgt2d5LXCdXzCYPoc", + TransactionType: "SetHook", + Fee: "2000000", + Hooks: + [ + { + Hook: {} + } + ] +} +``` + +### Create Operation + +**Occurs when**: + +_All_ of the following conditions are met: + +* The Corresponding Hook does not exist _or_`FLAG_OVERRIDE` is specified. +* `CreateCode` field is specified and is not blank and contains the valid web assembly bytecode for a valid Hook. +* No instance of the same web assembly bytecode already exists on Xahau. (If it does and all other requirements are met then interpret as an Install Operation — see below.) + +**Behaviour**: + +* A reference counted `HookDefinition` object is created on Xahau containing the fields in the HookSet Object, with all specified fields (Namespace, Parameters, HookOn) becoming defaults (but not Grants.) +* A `Hooks` array is created on the executing account, if it doesn't already exist. (This is the structure that contains the Corresponding Hooks.) +* A `Hook` object is created at the Corresponding Hook position if one does not already exist. +* The `Hook` object points at the `HookDefinition`. +* The `Hook` object contains no fields except `HookHash` which points at the created `HookDefinition`. +* If `hsfNSDELETE` flag is specified then any HookState entires in the destination namespace are deleted if they currently exist. + +**Example**: + +```json +{ + Account: "r4GDFMLGJUKMjNhhycgt2d5LXCdXzCYPoc", + TransactionType: "SetHook", + Fee: "2000000", + Hooks: + [ + { + Hook: { + CreateCode: fs.readFileSync('accept.wasm').toString('hex').toUpperCase(), + HookOn: '0000000000000000', + HookNamespace: addr.codec.sha256('accept').toString('hex').toUpperCase(), + HookApiVersion: 0 + } + } + ] +} +``` + +### Install Operation + +**Occurs when**: + +_All_ of the following conditions are met: + +* The Corresponding Hook does not exist _or_`FLAG_OVERRIDE` is specified. +* `HookHash` field is specified and is not blank and contains the hash of a Hook that already exists as a `HookDefinition` on the ledger _or_ `CreateCode` field is specified and is not blank and contains the valid web assembly bytecode for a valid hook that already exists on the ledger as a `HookDefinition`. + +**Behaviour**: + +* The reference count of the `HookDefinition` object is incremented. +* A `Hooks` array is created on the executing account, if it doesn't already exist. (This is the structure that contains the Corresponding Hooks.) +* A `Hook` object is created at the Corresponding Hook position if one does not already exist. +* The `Hook` object points at the `HookDefinition`. +* The `Hook` object contains all the fields in the HookSet Object, except and unless: +* A field or key-pair within a field is identical to the Hook Defaults set on the `HookDefinition`, in which case it is omitted due to defaults. +* If `hsfNSDELETE` flag is specified then any HookState entires in the destination namespace are deleted if they currently exist. + +**Example**: + +```json +{ + Account: "r4GDFMLGJUKMjNhhycgt2d5LXCdXzCYPoc", + TransactionType: "SetHook", + Fee: "2000000", + Hooks: + [ + { + Hook: { + HookHash: "A5663784D04ED1B4408C6B97193464D27C9C3334AAF8BBB4FA5EB8E557FC4A2C", + HookOn: '0000000000000000', + HookNamespace: addr.codec.sha256('accept').toString('hex').toUpperCase(), + } + } + ] +} +``` + +### Update Operation + +**Occurs when**: + +_All_ of the following conditions are met: + +* The Corresponding Hook exists. +* `HookHash` is absent. +* `CreateCode` is absent. +* One or more of `HookNamespace`, `HookParameters` or `HookGrants` is present. + +**General Behaviour**: + +* The Corresponding Hook is updated in such a way that the desired changes are reflected in the Corresponding Hook. + +**Specific Behaviour**: + +If `HookNamespace` is specified and differs from the Corresponding Hook's Namespace: + +* the Corresponding Hook's `HookNamespace` is updated, and +* if the `hsfNSDELETE` flag is specified all HookState entires in the old namespace are deleted. + +If `HookParameters` is specified, then for each entry: + +* If `HookParameterName` exists but `HookParameterValue` is absent and the Corresponding Hook's Parameters (either specifically or via defaults) contains this `HookParameterName` then the parameter is marked as deleted on the Corresponding Hook. +* If `HookParameterName` exists and `HookParameterValue` exists then the Corresponding Hook's Parameters are modified to include the new or updated parameter. + +If `HookGrants` is specified then: + +* The Corresponding Hook's `HookGrants` array is replaced with the array. + +**Example**: + +```json +{ + Account: "r4GDFMLGJUKMjNhhycgt2d5LXCdXzCYPoc", + TransactionType: "SetHook", + Fee: "2000000", + Hooks: + [ + { + Hook: { + HookNamespace: addr.codec.sha256('new_accept').toString('hex').toUpperCase(), + } + } + ] +} +``` + +### Delete Operation + +**Occurs when**: + +_All_ of the following conditions are met: + +* The Corresponding Hook exists. +* `hsfOVERRIDE` is specified. +* optionally `hsfNSDELETE` is also specified. +* `HookHash` is absent. +* `CreateCode` is present but empty. + +**Behaviour**: + +* The reference count of the `HookDefinition` object is decremented. +* If the reference count is now zero the `HookDefintion` is removed from the ledger. +* The `Hook` object in the Corresponding Hook position is deleted, leaving an empty position. +* If `hsfNSDELETE` is specified the namespace and all HookState entries are also deleted. + +**Example**: + +```json +{ + Account: "r4GDFMLGJUKMjNhhycgt2d5LXCdXzCYPoc", + TransactionType: "SetHook", + Fee: "2000000", + Hooks: + [ + { + Hook: { + CreateCode: "", + Flags: 1, + } + } + ] +} +``` + +### Namespace Reset + +**Occurs when**: + +_All_ of the following conditions are met: + +* `flags` is present and `hsfNSDELETE` is set. `hsfOVERRIDE` can optionally also be specified if the Hook at this position is to be deleted. +* `HookNamespace` is specified. +* `CreateCode` is absent. +* `HookHash` is absent. +* `HookGrants`, `HookParameters`, `HookOn` and `HookApiVersion` are absent. + +**Behaviour**: + +* If the Corresponding Hook exists, it remains, nothing happens to it. +* A subset of HookState objects and the HookState directory for the specified namespace are removed from the ledger, up to the defined limit of 512. Further transactions are needed to continue the deletion process until all relevant records are removed. + +**Example**: + +```json +{ + Account: "r4GDFMLGJUKMjNhhycgt2d5LXCdXzCYPoc", + TransactionType: "SetHook", + Fee: "2000000", + Hooks: + [ + { + Hook: { + HookNamespace: addr.codec.sha256('accept').toString('hex').toUpperCase(), + Flags: 3, + } + } + ] +} +``` diff --git a/src/content/docs/br/docs/hooks/concepts/slots-and-keylets.mdx b/src/content/docs/br/docs/hooks/concepts/slots-and-keylets.mdx new file mode 100644 index 0000000..2b0dc9f --- /dev/null +++ b/src/content/docs/br/docs/hooks/concepts/slots-and-keylets.mdx @@ -0,0 +1,62 @@ +--- +title: Slots and Keylets +description: Inspect and manipulate on-ledger objects. +--- +import { Aside } from '@astrojs/starlight/components'; + +### Background + +Xahau contains numerous heterogenous object types which a Hook has read-access to. For example: _transactions_, _accounts_, _ledgers_, and the subcomponents of each of these, to name just a few. + +It is very easy to carelessly program a computer to do a lot of needless copy operations when disciplined access to the same underlying data (i.e. through a view) would suffice. The deliberate avoidance of copy operations in programming is referred to as [Zero copy](https://en.wikipedia.org/wiki/Zero-copy) in programming. + +With Hooks the same principle applies. We want to avoid copying where possible. In particular we want to avoid as much as possible needlessly copying large objects such as whole ledgers, we also want to avoid serializaing and unserializing these where possible. + +### What are slots? + +Slots are part of the Hook API and provide a zero-copy _heterogenous_ access system for on-ledger objects and transactions. + +* Each Hook has access to 255 slots during runtime. +* Each slot may be empty or may contain a _slotted_ object. +* The slot API allows traversal into inner objects, and allows these inner objects themselves to be slotted. +* The slot API allows slotted objects to be dumped to a buffer or otherwise read by the Hook. + +The avilable slot APIs are: + +| Hook API | What it does | +| -------------------------------------------------------------------- | -------------------------------------------------------------------------------------- | +| [slot](/docs/hooks/functions/slot/slot) | Serialize and output a slotted object | +| [slot_clear](/docs/hooks/functions/slot/slot_clear) | Free up a currently occupied slot | +| [slot_count](/docs/hooks/functions/slot/slot_count) | Count the elements of an array object in a slot | +| slot_id | Compute the canonical hash of the slotted object and return it | +| [slot_set](/docs/hooks/functions/slot/slot_set) | Locate an object based on its keylet and place it into a slot | +| [slot_subarray](/docs/hooks/functions/slot/slot_subarray) | Index into a slotted array and assign a sub-object to another slot | +| [slot_subfield](/docs/hooks/functions/slot/slot_subfield) | Index into a slotted object and assign a sub-object to another slot | +| [slot_type](/docs/hooks/functions/slot/slot_type) | Retrieve the field code of an object in a slot and, optionally, some other information | +| [slot_float](/docs/hooks/functions/slot/slot_float) | Parse the STI_AMOUNT in the specified slot and return it as an XFL enclosed number | +| [slot_size](/docs/hooks/functions/slot/slot_size) | Compute the serialized size of an object in a slot | + +### What are keylets? + +Keylets are used to locate (point to) on-ledger objects. In brief they are a _hash_ of identifying information from the object, which is the canonical _handle_ for that object. + +Hooks use a serialized 34 byte keylet format which can be derrived using the important [util_keylet](/docs/hooks/functions/utilities/util_keylet) function. Without this looking up and slotting objects would be generally impossible. + + + +### Example + +In the following example a 34 byte keylet for a `signers` object is used to slot that object. + +```c +uint8_t keylet[34]; +if (util_keylet(SBUF(keylet), KEYLET_SIGNERS, SBUF(hook_accid), 0, 0, 0, 0) != 34) + rollback(SBUF("Notary: Internal error, could not generate keylet"), 10); + +// then requesting XRPLD slot that keylet into a new slot for us +int64_t slot_no = slot_set(SBUF(keylet), 0); +if (slot_no < 0) + rollback(SBUF("Notary: Could not set keylet in slot"), 10); +``` diff --git a/src/content/docs/br/docs/hooks/concepts/state-management.mdx b/src/content/docs/br/docs/hooks/concepts/state-management.mdx new file mode 100644 index 0000000..c9d86ad --- /dev/null +++ b/src/content/docs/br/docs/hooks/concepts/state-management.mdx @@ -0,0 +1,65 @@ +--- +title: State Management +description: Hooks can read and save small pieces of on-ledger data 🚀 +--- +import { Aside } from '@astrojs/starlight/components'; + +### What is Hook State? + +[State](https://en.wikipedia.org/wiki/State_\(computer_science\)) in computer science describes information held by a system between executions (as distinct from inputs and outputs.) For example your browser leaves you logged in to a website even after you close and reopen it. The login cookie is held in the browser's _state_. + +**Hook State** refers to a key-value mapping that logically exists for each account on Xahau whether or not any keys are currently present. The keys are always 32 bytes (unsigned 256 bit integer) and the values are variable length with a maximum size determined by validator voting, at time of writing 256 bytes. + +State Management is achieved using + +* [state](/docs/hooks/functions/state/state) +* [state_set](/docs/hooks/functions/state/state_set) +* [state_foreign](/docs/hooks/functions/state/state_foreign) + +### Storing and fetching + +The below example uses the [state_set](/docs/hooks/functions/state/state_set) Hook API to assign the value `0xC001CAFE` to the key `0x0..000001` (uint256 = 1) in the Hook State of the Hook Account. + +```c +uint8_t key[32] = { + 0x00U, 0x00U, 0x00U, 0x00U, 0x00U, 0x00U, 0x00U, 0x00U, + 0x00U, 0x00U, 0x00U, 0x00U, 0x00U, 0x00U, 0x00U, 0x00U, + 0x00U, 0x00U, 0x00U, 0x00U, 0x00U, 0x00U, 0x00U, 0x00U, + 0x00U, 0x00U, 0x00U, 0x00U, 0x00U, 0x00U, 0x00U, 0x01U +}; +uint8_t value[4] = { 0xC0U, 0x01U, 0xCAU, 0xFEU }; +if (state_set(value, 4, key, 32) == 4) +{ + // ... state successfully saved +} +``` + +In a subsequent Hook execution this value can now be retrieved using the same key: + +```c +uint8_t value[4]; +uint8_t key[32] = { + 0x00U, 0x00U, 0x00U, 0x00U, 0x00U, 0x00U, 0x00U, 0x00U, + 0x00U, 0x00U, 0x00U, 0x00U, 0x00U, 0x00U, 0x00U, 0x00U, + 0x00U, 0x00U, 0x00U, 0x00U, 0x00U, 0x00U, 0x00U, 0x00U, + 0x00U, 0x00U, 0x00U, 0x00U, 0x00U, 0x00U, 0x00U, 0x01U +}; +if (state(value, 4, key, 32) < 0) +{ + // ... state fetch failed +} +``` + +After the above code has run the `value` buffer will be populated with the value found at the key. + + + +### Foreign state + +From time to time it may be advantageous for one Hook running on one account to read the Hook State of another Hook running on another account. The [state_foreign](/docs/hooks/functions/state/state_foreign) Hook API does exactly this. Because the ledger is public there is no reasonable expectation of privacy anyway. Any Hook may therefore _read_ (but not write) the Hook State of any other Hook. + +### Namespaces and querying + +Please see [Namespaces](/docs/hooks/concepts/namespaces) diff --git a/src/content/docs/br/docs/hooks/concepts/terminology.mdx b/src/content/docs/br/docs/hooks/concepts/terminology.mdx new file mode 100644 index 0000000..cb0880f --- /dev/null +++ b/src/content/docs/br/docs/hooks/concepts/terminology.mdx @@ -0,0 +1,38 @@ +--- +title: Terminology +description: Welcome to Hooks 👋 +--- +### What are Hooks? + +Hooks are small, efficient web assembly modules designed specifically for Xahau. Hooks can be written in any language (compilable to WebAssembly) and most business logic and most smart contract concepts can be implemented in a hook. Typically Hooks are written in C. + +Hooks are set onto an Xahau account using a `SetHook` transaction. Once installed on an account, a hook can: + +1. Block or allow incoming and outgoing transactions on the account, +2. Modify and maintain internal state and logic specific to the hook on that account, and +3. Emit new transactions on behalf of the account. + +### Glossary + +This Hooks documentation and the Hooks API use a set of unfamiliar terms. Use the lookup table below if you find yourself lost. + +| Term | Explanation | +| ------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Hook |

This term refers to a range of things depending on context
1. A webassembly binary uploadable to Xahau with the SetHook Transaction type.
2. A webassembly binary already uploaded to and set or configured onto an Xahau account.
3. The source code of such a binary.

| +| Originating Transaction | The transaction that triggered the Hook to fire. This could be either a transaction sent out of or into an account with a Hook set on it. | +| Originating Account | The account that sent an Originating Transaction. | +| Hook Account | The account where the currently executing Hook lives. This is the account that owns the Hook, the account that performed the [SetHook Transaction](/docs/hooks/concepts/sethook-transaction) which created the Hook and the account to whom belongs the Hook State for the currently executing Hook. | +| Installer | The account which is currently installing a Hook using the SetHook transaction. | +| Emitted Transaction | A new transaction created by a Hook during the Hook's execution that is not the Originating Transaction. These are typically used for sending funds back to the Originating Account. See: [Emitted Transactions](/docs/hooks/concepts/emitted-transactions). | +| State | A per-account key-value map of 32 byte keys to arbitrary data. All Hooks present on an account have access to the same Hook State and can modify it. Note that the Hook State lives on the Hook Account **not** on the Originating Account. See: [State Management](/docs/hooks/concepts/state-management). | +| SetHook | A new Transaction Type introduced in the Hooks ammendment which sets a Hook onto an Xahau account. See: [SetHook Transaction](/docs/hooks/concepts/sethook-transaction). | +| Guards | A special control mechanism you need to use if you write a loop into in a Hook. See: [Loops and Guarding](/docs/hooks/concepts/loops-and-guarding). | +| Grants | Special permission a Hook Installer can give another account or a specific Hook (regardless of where it is installed) to modify Hook State on the Installer's account. | +| Namespace | A unique 32 byte code delineating one set of state keys from another. The same state key may be used by two different Hooks without interfering with each-other if the namespaces set on the Hooks are different. | +| Parameters | Install-time parameters that can be optionally set on a Hook. | +| Reference Counting | An unowned object on the ledger may be reference counted, meaning it is deleted when the final account which referenced (used) it removes their reference to it. | +| XFL or Floating Point | A way to do high precision math in Hooks such as for exchange rate computation. See: [Floating Point Numbers (XFL)](/docs/hooks/concepts/floating-point-numbers-xfl). | +| Serialized Objects (STO) | The way xahaud transmits and stores ledger objects. See: [Serialized Objects](/docs/hooks/concepts/serialized-objects). | +| Slots and Keylets | Slots can contain ledger objects and keylets identify those objects. See: [Slots and Keylets](/docs/hooks/concepts/slots-and-keylets). | +| Trace | A way to print a log line to the xrpld output from a Hook. See: [Debugging Hooks](/docs/hooks/concepts/debugging-hooks). | + diff --git a/src/content/docs/br/docs/hooks/concepts/weak-and-strong.mdx b/src/content/docs/br/docs/hooks/concepts/weak-and-strong.mdx new file mode 100644 index 0000000..64e3ba0 --- /dev/null +++ b/src/content/docs/br/docs/hooks/concepts/weak-and-strong.mdx @@ -0,0 +1,242 @@ +--- +title: Weak and Strong +description: Which Hooks are allowed to run and when? +--- +import { Aside } from '@astrojs/starlight/components'; + + + +Transactional Stake Holders (TSH) are parties that somehow have a stake in or are otherwise affected by a transaction. Their particular stake may be a _weak_ or _strong_. The degree of connection with the transaction dictates whether the party has the right to have their Hooks executed and who has to pay for that execution. + +For example: + +* In a conventional direct XAH **Payment** transaction the two TSH are the _originating account_ and the _destination account_. +* In a **SetSignerList** transaction the TSH are the _originating account_ and each account whose address appears in the signer list, where such accounts are active on the ledger. +* In an **OfferCreate** transaction, other account's offers which are crossed by the originating transaction are all weak TSH and may opt for weak execution. +* With the **IOUIssuerWeakTSH** amendment, currency issuers have their hooks executed in third-party transactions that touch or mention their currency, if they have opted into weak execution. + +Due to the heterogenous nature of transactions on Xahau, TSH come in all shapes and sizes and can be exotic and non-intuitive. This becomes more true as time passes and more transaction types are added to the Ledger. + +### Weak and Strong + +Each TSH has either a weak or a strong connection to the transaction. + +A **Strong** connection means: + +1. The originating transaction must pay the fee for the execution of the TSH Hook Chain +2. The TSH has the right to rollback the whole transaction by calling `rollback()` from their Hook during execution. + +A **Weak** connection means: + +1. The originating transaction **does not** pay for the execution of the TSH Hook Chain. +2. The TSH pays for the execution of their own Hook Chain through a feature called [Collect Call Hooks](/docs/hooks/concepts/collect-call). +3. The TSH must have set an account flag `asfTshCollect` prior to the execution of the originating transaction. +4. The TSH **does not** have the right to rollback the whole transaction by calling `rollback()` from their Hook during execution (but can still modify their own Hook state and Emit transactions.) + +### Before or After + +Strong TSHes have their hooks executed _before_ the originating transaction is applied to the ledger. This means they have the ability to [rollback](/docs/hooks/functions/control/rollback) the transaction (because it hasn't yet been applied.) This gives strongly executed hooks the ability to completely block a transaction from occurring. + +Weak TSHes have their hooks executed _after_ the originating transaction has been applied to the ledger. This means they have access to the [transaction metadata](/docs/hooks/functions/originating-transaction/meta_slot) but cannot prevent the transaction from occurring. + + + +### Execution Context + +The `uint32_t` parameter in `hook(uint32_t)` and `cbak(uint32_t)` carries important context information from the Hooks Amendment to your Hook. + +During the execution of `hook`: + +* 0 means the Hook is being executed _strongly_ +* 1 means the Hook is being executed _weakly_ +* 2 means the Hook is being executed _weakly_ after being executed _strongly_ due to a [hook_again](/docs/hooks/functions/hook-context/hook_again) call. + +During the execution of `cbak`: + +* 0 means the Hook is being called back after a transaction it emitted was successfully accepted into a ledger. +* 1 means the Hook is being called back after a transaction it emitted was marked as never able to be applied to any ledger (EmitFailure). + +### Reference Table + +If a Transaction Type does not appear in the table then it has no TSHes **other than its originating account.** + + + +| Transaction Type | TSH Type | Who is the TSH | +| ----------------------- | ------------- | -------------------------------------------------------------------------------------------- | +| AccountDelete | Strong | Destination account funds are paid out to after deletion | +| AccountSet | None | N/A | +| CheckCancel | Weak | Destination account | +| CheckCash | None | N/A | +| CheckCreate | Strong | Destination account | +| ClaimReward | Strong | Issuer Account | +| DepositPreauth | Strong | Authorized account | +| EscrowCancel | Weak | Destination account | +| EscrowCreate | Strong | Destination account | +| EscrowFinish | Strong | Destination account | +| GenesisMint | Weak | Each Destination in the GenesisMints Array | +| Import | Strong | Issuer Account | +| Invoke | Strong | Destination account | +| OfferCancel | None | N/A | +| OfferCreate | Weak | Accounts whose offers were crossed by this action. | +| Payment | Strong + Weak | Strong: Destination account. Weak: Any non-issuer the payment is rippled through. | +| PaymentChannelClaim | Weak | Destination account | +| PaymentChannelCreate | Strong | Destination account | +| PaymentChannelFund | Weak | Destination account | +| SetHook | None | N/A | +| SetRegularKey | Strong | The account whose address is being set as the key. | +| SignerListSet | Strong | Accounts whose addresses are set as signing keys (if they exist and have Hooks set on them). | +| TicketCreate | None | N/A | +| TrustSet | Weak | Issuer account | +| URITokenCancelSellOffer | None | N/A | +| URITokenCreateSellOffer | Strong | Destination account, Issuer if tfBurnable Flag is set | +| URITokenBurn | Strong | Issuer if tfBurnable Flag is set | +| URITokenBuy | Strong | Owner account, Issuer if tfBurnable Flag is set | +| URITokenMint | None | N/A | + +**AccountSet** + +| OTXN | TSH | AccountSet | +| ------- | ------- | ---------- | +| Account | Account | Strong | + +**AccountDelete** + +| OTXN | TSH | AccountDelete | +| ------- | ----------- | ------------- | +| Account | Account | None | +| Account | Beneficiary | Strong | + +**Check** + +| OTXN | TSH | CheckCancel | CheckCreate | CheckCash | +| ----------- | ----------- | ----------- | ----------- | --------- | +| Account | Account | Strong | Strong | None | +| Account | Destination | Weak | Strong | None | +| Destination | Destination | Strong | None | Strong | +| Destination | Account | Weak | None | Weak | + +**ClaimReward** + +| OTXN | TSH | ClaimReward | +| ------- | ------- | ----------- | +| Account | Account | Strong | +| Account | Issuer | Strong | + +**DepositPreauth** + +| OTXN | TSH | DepositPreauth | +| ------- | ---------- | -------------- | +| Account | Account | Strong | +| Account | Authorized | Strong | + +**Escrow** + +| OTXN | TSH | EscrowCancel | EscrowCreate | EscrowFinish | +| ----------- | ----------- | ------------ | ------------ | ------------ | +| Account | Account | Strong | Strong | Strong | +| Account | Destination | Weak | Strong | Weak | +| Destination | Destination | Strong | None | Strong | +| Destination | Account | Weak | None | Weak | + +**GenesisMint** + +| OTXN | TSH | GenesisMint | +| ------- | ----------- | ----------- | +| Account | Account | Strong | +| Account | Destination | Strong | +| Account | Beneficiary | Weak | + +**Import** + +| OTXN | TSH | Import | +| ------- | ------- | ------ | +| Account | Account | Strong | +| Account | Issuer | Strong | + +**Invoke** + +| OTXN | TSH | Invoke | +| ------- | ----------- | ------ | +| Account | Account | Strong | +| Account | Destination | Weak | + +**Offer** + +| OTXN | TSH | OfferCancel | OfferCreate | +| ------- | ------- | ----------- | ----------- | +| Account | Account | Strong | Strong | +| Account | Crossed | None | Weak | + +**Payment** + +| OTXN | TSH | Payment | +| ------- | ----------- | ------- | +| Account | Account | Strong | +| Account | Destination | Strong | +| Account | Crossed | Weak | + +**PaymentChannel** + +| OTXN | TSH | PaymentChannelClaim | PaymentChannelCreate | PaymentChannelFund | +| ----------- | ----------- | ------------------- | -------------------- | ------------------ | +| Account | Account | Strong | Strong | Strong | +| Account | Destination | Weak | Strong | Weak | +| Destination | Destination | Strong | None | None | +| Destination | Account | Weak | None | None | + +**SetHook** + +| OTXN | TSH | SetHook | +| ------- | ------- | ------- | +| Account | Account | Strong | + +**SetRegularKey** + +| OTXN | TSH | SetRegularKey | +| ------- | ---------- | ------------- | +| Account | Account | Strong | +| Account | RegularKey | Strong | + +**SignerListSet** + +| OTXN | TSH | SignerListSet | +| ------- | ------- | ------------- | +| Account | Account | Strong | +| Account | Signer | Strong | + +**Ticket** + +| OTXN | TSH | TicketCreate | +| ------- | ------- | ------------ | +| Account | Account | Strong | + +**TrustSet** + +| OTXN | TSH | TrustSet | +| ------- | ------- | -------- | +| Account | Account | Strong | +| Account | Issuer | Weak | + +**URIToken** + +| OTXN | Burnable | TSH | Mint | Burn | Buy | Sell | Cancel | +| ------ | -------- | ------ | ------ | ------ | ------ | ------ | ------ | +| Owner | False | Owner | None | Strong | Strong | Strong | Strong | +| Owner | False | Issuer | None | Weak | Weak | Weak | None | +| Owner | False | Buyer | None | None | None | Strong | Weak | +| Owner | True | Buyer | None | None | None | Strong | Weak | +| Owner | True | Owner | None | Strong | Strong | Strong | Strong | +| Owner | True | Issuer | None | Weak | Strong | Strong | None | +| Issuer | False | Owner | None | None | None | None | None | +| Issuer | False | Issuer | Strong | None | None | None | None | +| Issuer | False | Buyer | Weak | None | None | None | None | +| Issuer | True | Owner | None | Weak | None | None | None | +| Issuer | True | Issuer | Strong | Strong | None | None | None | +| Issuer | True | Buyer | Weak | None | None | None | None | +| Buyer | True | Buyer | None | None | Strong | None | None | +| Buyer | True | Owner | None | None | Weak | None | None | diff --git a/src/content/docs/br/docs/hooks/functions/control/accept.mdx b/src/content/docs/br/docs/hooks/functions/control/accept.mdx new file mode 100644 index 0000000..f5eb713 --- /dev/null +++ b/src/content/docs/br/docs/hooks/functions/control/accept.mdx @@ -0,0 +1,101 @@ +--- +title: accept +description: Accept the originating transaction and commit any changes the hook made. +--- +import { Tabs, TabItem, LinkButton, Aside } from '@astrojs/starlight/components'; + +### Concepts + +Introduction +Execution Metadata + +### Behaviour + +End the execution of the hook with status: success. + +* Record a return string and return code in transaction metadata. +* Commit all state changes. +* Submit all `emit()` transactions. +* Allow originating transaction to continue. + + + +### Definition + + + +```c +int64_t accept ( + uint32_t read_ptr, + uint32_t read_len, + uint64_t error_code +); +``` + + + +```javascript +function accept(msg: string, code: number): number +``` + + + + + +### Example + + + +```c +accept("Success", 7, 100); +``` + + + +```javascript +accept('Success', 100) +``` + + + + + +### Parameters + + + +| Name | Type | Description | +| ----------- | --------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| read_ptr | uint32_t |

Pointer to a return string to be stored in execution metadata.
This is any string the hook-developer wishes to return with the acceptance. May be null.

| +| read_len | uint32_t | The length of the return string. At most 32. _May be null._ | +| error_code | uint64_t |

A return code specific to this hook to be stored in execution metadata.

Similar to the return code of an application on a *nix system. By convention success is zero.

| + + + +| Name | Type | Description | +| ---- | ------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| msg | string |

String to be stored in execution metadata.
This is any string the hook-developer wishes to return with the acceptance. May be null.

| +| code | number |

A return code specific to this hook to be stored in execution metadata.

Similar to the return code of an application on a *nix system. By convention success is zero.

| + + + + + +### Return Code + + + +| Type | Description | +| -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- | +| int64_t | Accept ends the hook, therefore no value is returned to the caller. By convention all Hook APIs return `int64_t`, but in this case nothing is returned. | + + + +| Type | Description | +| ------ | -------------------------------------------------------------------------------------------------------------------------------------------------------- | +| number | Accept ends the hook, therefore no value is returned to the caller. By convention all Hook APIs return `a number`, but in this case nothing is returned. | + + + diff --git a/src/content/docs/br/docs/hooks/functions/control/rollback.mdx b/src/content/docs/br/docs/hooks/functions/control/rollback.mdx new file mode 100644 index 0000000..0f70e80 --- /dev/null +++ b/src/content/docs/br/docs/hooks/functions/control/rollback.mdx @@ -0,0 +1,80 @@ +--- +title: rollback +--- +import { Aside, Tabs, TabItem, LinkButton } from '@astrojs/starlight/components'; + +### Concepts + +Introduction +Execution Metadata + +### Behaviour + +End the execution of the hook with status: reject. + +* Record a return string and return code in transaction metadata. +* Discard all state changes. +* Discard all `emit()` transactions. +* Disallow originating transaction to continue. + + + +### Definition + + + +```c +int64_t rollback ( + uint32_t read_ptr, + uint32_t read_len, + uint64_t error_code +); +``` + + +```javascript +function rollback(error_msg: string, error_code: number): number +``` + + + +### Example + + + +```c +rollback("Rejected!", 9, 100); +``` + + +```javascript +rollback('Rejected!', 100) +``` + + + +### Parameters + + + + +
NameTypeDescription
read_ptruint32_tPointer to a return string to be stored in execution metadata.
This is any string the hook-developer wishes to return with the acceptance. May be null.
read_lenuint32_tThe length of the return string. At most 32. May be null.
error_codeuint64_tA return code specific to this hook to be stored in execution metadata.

Similar to the return code of an application on a *nix system. By convention non-success is non-zero.
+ + + +
NameTypeDescription
error_msgstringString to be stored in execution metadata.
This is any string the hook-developer wishes to return with the acceptance. May be null.
error_codenumberA return code specific to this hook to be stored in execution metadata.

Similar to the return code of an application on a *nix system. By convention non-success is non-zero.
+ + + +### Return Code + + + +
TypeDescription
int64_tRollback ends the hook, therefore no value is returned to the caller. By convention all Hook APIs return int64_t, but in this case nothing is returned.
+ + +
TypeDescription
numberRollback ends the hook, therefore no value is returned to the caller. By convention all Hook APIs return number, but in this case nothing is returned.
+ + diff --git a/src/content/docs/br/docs/hooks/functions/developer-defined/cbak-callback.mdx b/src/content/docs/br/docs/hooks/functions/developer-defined/cbak-callback.mdx new file mode 100644 index 0000000..72ee204 --- /dev/null +++ b/src/content/docs/br/docs/hooks/functions/developer-defined/cbak-callback.mdx @@ -0,0 +1,91 @@ +--- +title: cbak / Callback +description: The callback function of your hook +--- +import { Tabs, TabItem, LinkButton } from '@astrojs/starlight/components'; + +### Concepts + +Compiling Hooks + +### Behaviour + +* `cbak` is a user defined function called by `xahaud` in order to inform your hook about the status of a previously emitted transaction +* State changes and further emit calls can be made from cbak but it cannot `rollback` a transaction. +* When cbak is executed the emitted transaction to which the callback relates is now the originating transaction. + +### Definition + + + +```c +int64_t cbak ( + uint32_t what +) +``` + + + +```javascript +type Callback = (reserved: number) => number +``` + + + +### Example + + + + + +```c +int64_t cbak(uint32_t reserved) +{ + return 0; +} +``` + + + + + +```javascript +const Callback = (reserved: number) => { + return 0 +} +``` + + + +### Parameters + + + +| Name | Type | Description | +| -------- | --------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| reserved | uint32_t |

if 0:
- the emittted transaction to which this callback relates was successfully accepted into a ledger.

If 1
- the emitted transaction to which the callback relates was NOT successfully accepted into a ledger before it expired.

| + + + +| Name | Type | Description | +| -------- | ------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| reserved | number |

if 0:
- the emittted transaction to which this callback relates was successfully accepted into a ledger.

If 1
- the emitted transaction to which the callback relates was NOT successfully accepted into a ledger before it expired.

| + + + +### Return Code + + + +| Type | Description | +| -------- | -------------------------------------------------------------------------------------------------------------------------------- | +| int64_t | An arbitrary return code you wish to return from your hook. This will be present in the metadata of the originating transaction. | + + + +| Type | Description | +| ------ | -------------------------------------------------------------------------------------------------------------------------------- | +| number | An arbitrary return code you wish to return from your hook. This will be present in the metadata of the originating transaction. | + + + diff --git a/src/content/docs/br/docs/hooks/functions/developer-defined/hook.mdx b/src/content/docs/br/docs/hooks/functions/developer-defined/hook.mdx new file mode 100644 index 0000000..ab031e3 --- /dev/null +++ b/src/content/docs/br/docs/hooks/functions/developer-defined/hook.mdx @@ -0,0 +1,95 @@ +--- +title: hook +description: The main function of your hook +--- +import { Tabs, TabItem, LinkButton } from '@astrojs/starlight/components'; + +### Concepts + +Compiling Hooks + +### Behaviour + +* `hook` is a user defined function called by `xahaud` in order to fire your hook. +* Your `hook` function calls either `accept` or `reject` to pass or reject the originating transaction. +* If execution reaches the end of the function it is implicitly an `accept`. + +### Definition + + + +```c +int64_t hook ( + uint32_t reserved +) +``` + + + + + +```javascript +type Hook = (reserved: number) => number +``` + + + + + + + +### Example + + + +```c +int64_t hook(uint32_t reserved) +{ + return 0; +} +``` + + + + + +```javascript +const Hook = (reserved: number) => { + return 0 +} +``` + + + +### Parameters + + + +
NameTypeDescription
reserveduint32_tReserved for future use.
+ + + + + +
NameTypeDescription
reservednumberReserved for future use.
+ + + +### Return Code + + + +| Type | Description | +| -------- | -------------------------------------------------------------------------------------------------------------------------------- | +| int64_t | An arbitrary return code you wish to return from your hook. This will be present in the metadata of the originating transaction. | + + + + + +| Type | Description | +| ------ | -------------------------------------------------------------------------------------------------------------------------------- | +| number | An arbitrary return code you wish to return from your hook. This will be present in the metadata of the originating transaction. | + + + diff --git a/src/content/docs/br/docs/hooks/functions/emitted-transaction/emit-1.mdx b/src/content/docs/br/docs/hooks/functions/emitted-transaction/emit-1.mdx new file mode 100644 index 0000000..9db8215 --- /dev/null +++ b/src/content/docs/br/docs/hooks/functions/emitted-transaction/emit-1.mdx @@ -0,0 +1,111 @@ +--- +title: emit +description: Emit a new transaction from the hook +--- +import { Tabs, TabItem, LinkButton } from '@astrojs/starlight/components'; + +### Concepts + +Emitted Transactions + +### Behaviour + + + +* Read a transaction from `read_ptr` +* Validate the transaction against the emission rules +* Emit the transaction into consensus when valid +* Write canonical transaction hash to `write_ptr` + + + +* This function emits the provided transaction JSON. +* On success, it returns the number of emitted transaction hashes. +* If there is an error, it returns an error code. + + + +### Definition + + + +```c +int64_t emit ( + uint32_t write_ptr, + uint32_t write_len, + uint32_t read_ptr, + uint32_t read_len +); +``` + + + + + +```javascript +function emit( + txJson: Record | Transaction + ): ErrorCode | ByteArray +``` + + + + + +### Example + + + +```c +if (emit(tx, tx_len) < 0) + rollback("Failed to emit!", 15, 1); +``` + + + + + +```javascript +const emitResult = emit(txJson) +if(typeof emitResult === 'number') + rollback("Failed to emit!", 1) +``` + + + + + +### Parameters + + + +
NameTypeDescription
write_ptruint32_tPointer to a buffer to write the transaction hash to
write_lenuint32_tThe size of the buffer to write the transaction hash to (should be 32.)
read_ptruint32_tPointer to the transaction to emit
read_lenuint32_tThe length of the transaction
+ + + + + + + +
NameTypeDescription
txJsonRecord<string, any> | TransactionThe TX JSON to emit.
+ + + + + +### Return Code + + + +
TypeDescription
int64_tOn success, the number of bytes of transaction hash written (32), or:

If negative, an error:
OUT_OF_BOUNDS
- pointers/lengths specified outside of hook memory.

PREREQUISITE_NOT_MET
- emit_reserve must be called first

TOO_MANY_EMITTED_TXN
- the number of emitted transactions is now greater than the promise made when emit_reserve was called earlier

EMISSION_FAILURE
- the transaction was malformed according to the emission rules.
+ + + + + + + +
TypeDescription
ErrorCode | ByteArrayReturns an ErrorCode if there is an error, or an array of emitted transaction hashes on success.
+ + + diff --git a/src/content/docs/br/docs/hooks/functions/emitted-transaction/emit.mdx b/src/content/docs/br/docs/hooks/functions/emitted-transaction/emit.mdx new file mode 100644 index 0000000..8c42d18 --- /dev/null +++ b/src/content/docs/br/docs/hooks/functions/emitted-transaction/emit.mdx @@ -0,0 +1,71 @@ +--- +title: prepare +description: Prepares a JSON transaction for emission. +--- +import { Tabs, TabItem, LinkButton } from '@astrojs/starlight/components'; + +### Concepts + +Transactions + +### Behaviour + + + +* This function takes a transaction JSON object and prepares it for emission. +* The transaction must be complete except for the Account field, which should always be the Hook account. + + + +### Definition + + + +```javascript +function prepare( + txJson: Record | Transaction + ): ErrorCode | Record | Transaction +``` + + + + + +### Example + + + +```javascript +const prepared_txn = prepare({ + TransactionType: "Payment", + Destination: util_raddr(p1address_ns), + Amount: parseFloat(drops_sent)*2 + }) +``` + + + + + +### Parameters + + + + + +
NameTypeDescription
txJsonRecord<string, any> | TransactionThe transaction JSON, must be a complete transaction except for Account (always the Hook account).
+ + + + + +### Return Code + + + + + +
TypeDescription
ErrorCode | Record<string, any> | TransactionReturns an ErrorCode if there is an error, or the prepared transaction JSON or Transaction object.
+ + + diff --git a/src/content/docs/br/docs/hooks/functions/emitted-transaction/etxn_burden.mdx b/src/content/docs/br/docs/hooks/functions/emitted-transaction/etxn_burden.mdx new file mode 100644 index 0000000..7c7fcdb --- /dev/null +++ b/src/content/docs/br/docs/hooks/functions/emitted-transaction/etxn_burden.mdx @@ -0,0 +1,70 @@ +--- +title: etxn_burden +description: Get the burden of a hypothetically emitted transaction +--- +import { Tabs, TabItem, LinkButton } from '@astrojs/starlight/components'; + +### Concepts + +Emitted Transactions + +### Behaviour + +* Return the burden an emitted transaction will carry. + +### Definition + + + +```c +int64_t etxn_burden ( + void +); +``` + + + +```javascript +function etxn_burden(): ErrorCode | number +``` + + + + + +### Example + + + +```c +int64_t burden = etxn_burden(); +``` + + + + + +```javascript +const burden = etxn_burden() +``` + + + + + +### Parameters + +None + +### Return Code + + + +
TypeDescription
int64_tThe burden an emitted transaction will need in order to be successfully passed to emit()
+ + + +
TypeDescription
numberAn ErrorCode if there is an error, or the current burden value on success.
+ + + diff --git a/src/content/docs/br/docs/hooks/functions/emitted-transaction/etxn_details.mdx b/src/content/docs/br/docs/hooks/functions/emitted-transaction/etxn_details.mdx new file mode 100644 index 0000000..2180d66 --- /dev/null +++ b/src/content/docs/br/docs/hooks/functions/emitted-transaction/etxn_details.mdx @@ -0,0 +1,114 @@ +--- +title: etxn_details +description: Produce an sfEmitDetails suitable for a soon-to-be emitted transaction +--- +import { Tabs, TabItem, LinkButton } from '@astrojs/starlight/components'; + +### Concepts + +Emitted Transactions + +### Behaviour + + + +* Generate and write a 105 byte sfEmitDetails object into the `write_ptr` if cbak is not defined +* Generate and write a 127 byte sfEmitDetails object into the `write_ptr` if cbak is defined. + + + +* This function provides detailed information about the transaction. +* Returns an ErrorCode if there is an error, or an array of transaction details on success. + + + + + +### Definition + + + +```c +int64_t etxn_details ( + uint32_t write_ptr, + uint32_t write_len +); +``` + + + + + +```javascript +function etxn_details(): ErrorCode | ByteArray +``` + + + + + +### Example + + + +```c +uint8_t emitdet[105]; +int64_t result = + etxn_details(emitdet, 105); +if (result != 105) + rollback("Etxndetails failed.", 19, 1); +``` + + + + + +```javascript +const emitdet = etxn_details() +if (typeof emitdet === 'string || emitdet.length != 105) + rollback("Etxndetails failed.", 1) +``` + + + + + +### Parameters + + + +| Name | Type | Description | +| ---------- | --------- | -------------------------------------------------------- | +| write_ptr | uint32_t | Pointer to the buffer receiving the sfEmitDetails record | +| write_len | uint32_t | Length of the buffer | + + + + + +No parameters for JavaScript + + + + + +### Return Code + + + +| Type | Description | +| -------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| int64_t |

The number of bytes written.

If negative, an error:
OUT_OF_BOUNDS
- pointers/lengths specified outside of hook memory.

TOO_SMALL
- Buffer isn't large enough to receive record

PREREQUISITE_NOT_MET
- The hook failed to call etxn_reserve(n) first

FEE_TOO_LARGE
- The burden would be too high for the network to allow.

INTERNAL_ERROR
- A generic error in which rippled had trouble generating the required field.

| + + + + + + + +| Type | Description | +| ---------------------- | --------------------------------------------------------------------------------- | +| ErrorCode | ByteArray | An ErrorCode if there is an error, or an array of transaction details on success. | + + + diff --git a/src/content/docs/br/docs/hooks/functions/emitted-transaction/etxn_fee_base.mdx b/src/content/docs/br/docs/hooks/functions/emitted-transaction/etxn_fee_base.mdx new file mode 100644 index 0000000..4b77137 --- /dev/null +++ b/src/content/docs/br/docs/hooks/functions/emitted-transaction/etxn_fee_base.mdx @@ -0,0 +1,99 @@ +--- +title: etxn_fee_base +--- +import { Tabs, TabItem, LinkButton, Aside } from '@astrojs/starlight/components'; + + + +### Concepts + +Emitted Transactions + +### Behaviour + +* Return the amount of the fee in drops recommended for a to-be emitted transaction. + +### Definition + + + +```c +int64_t etxn_fee_base ( + uint32_t read_ptr, + uint32_t read_len +); +``` + + + + + +```javascript +function etxn_fee_base(txblob: ByteArray | HexString): ErrorCode | number +``` + + + + + +### Example + + + +```c +int64_t fee_to_pay = + etxn_fee_base(tx_blob, tx_blob_len); +``` + + + + + +```javascript +const fee_to_pay = etxn_fee_base(tx_blob) +``` + + + + + +### Parameters + + + +
NameTypeDescription
read_ptruint32_tPointer to the buffer containing the serialized transaction you intend to emit. The fee field is required but ignored (you may use zero). Use the output of this function to populate the fee field correctly.
read_lenuint32_tThe length of the tx blob.
+ + + + + + + +
NameTypeDescription
txblobByteArray | HexStringThe transaction blob, which can be an array of numbers or a string.
+ + + + + +### Return Code + + + + + +| Type | Description | +| -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| int64_t |

The smallest number of drops that an emitted txn would need to be accepted.

If negative, an error:
OUT_OF_BOUNDS
- The provided buffer is not validly within the hook memory.

PREREQUISITE_NOT_MET
- etxn_reserve has not been called first.

INVALID_TXN
- The provided buffer did not contain a valid serialized transaction. (Deserialization failed, or a required field was missing.)

| + + + + + +| Type | Description | +| ------ | ------------------------------------------------------------------------- | +| number | An ErrorCode if there is an error, or the calculated base fee on success. | + + + diff --git a/src/content/docs/br/docs/hooks/functions/emitted-transaction/etxn_generation.mdx b/src/content/docs/br/docs/hooks/functions/emitted-transaction/etxn_generation.mdx new file mode 100644 index 0000000..5486c11 --- /dev/null +++ b/src/content/docs/br/docs/hooks/functions/emitted-transaction/etxn_generation.mdx @@ -0,0 +1,79 @@ +--- +title: etxn_generation +description: Get the generation of a hypothetically emitted transaction +--- +import { Tabs, TabItem, LinkButton } from '@astrojs/starlight/components'; + +### Concepts + +Emitted Transactions + +### Behaviour + +* Return the generation an emitted transaction will carry. + +### Definition + + + +```c +int64_t etxn_generation ( + void +); +``` + + + + + +```javascript +function etxn_generation(): ErrorCode | number +``` + + + + + +### Example + + + +```c +int64_t generation = + etxn_generation(); +``` + + + +```javascript +const generation = etxn_generation() +``` + + + + + +### Parameters + +None + +### Return Code + + + +| Type | Description | +| -------- | ---------------------------------------------------------------------------------------------- | +| int64_t | The generation an emitted transaction will need in order to be successfully passed to `emit()` | + + + + + + + +| Type | Description | +| ------ | --------------------------------------------------------------------------------------------------- | +| number | Returns An ErrorCode if there is an error, or a number indicating the generation result on success. | + + + diff --git a/src/content/docs/br/docs/hooks/functions/emitted-transaction/etxn_nonce.mdx b/src/content/docs/br/docs/hooks/functions/emitted-transaction/etxn_nonce.mdx new file mode 100644 index 0000000..5f58266 --- /dev/null +++ b/src/content/docs/br/docs/hooks/functions/emitted-transaction/etxn_nonce.mdx @@ -0,0 +1,100 @@ +--- +title: etxn_nonce +description: Generate a 32 byte nonce for use in an emitted transaction +--- +import { Tabs, TabItem, LinkButton } from '@astrojs/starlight/components'; + +### Concepts + +Emitted Transactions + +### Behaviour + + + +* Write the 32 byte Hash to the write_ptr + + + +* Returns an ErrorCode if there is an error, or an array containing the nonce value on success. + + + + + +### Definition + + + +```c +int64_t etxn_nonce ( + uint32_t write_ptr, + uint32_t write_len +); +``` + + + + + +```javascript +function etxn_nonce(): ErrorCode | ByteArray +``` + + + + + +### Example + + + +```c +uint8_t n[32]; +int64_t bytes_written = + etxn_nonce(n, 32); +``` + + + + + +```javascript +const nonce = etxn_nonce() +``` + + + + + +### Parameters + + + + + +| Name | Type | Description | +| ---------- | --------- | ---------------------------------------------------------------------------------------- | +| write_ptr | uint32_t | Pointer to a buffer of a suitable size to store the output. Should be at least 32 bytes. | +| write_len | uint32_t | Length of the output buffer. | + + + +No parameters + + + + + +### Return Code + + + +
TypeDescription
int64_tThe number of bytes written

If negative, an error:
OUT_OF_BOUNDS
- pointers/lengths specified outside of hook memory.
+ + + +
TypeDescription
ErrorCode | ByteArrayReturns an ErrorCode if there is an error, or an array containing the nonce value on success.
+ + + diff --git a/src/content/docs/br/docs/hooks/functions/emitted-transaction/etxn_reserve.mdx b/src/content/docs/br/docs/hooks/functions/emitted-transaction/etxn_reserve.mdx new file mode 100644 index 0000000..ea569ef --- /dev/null +++ b/src/content/docs/br/docs/hooks/functions/emitted-transaction/etxn_reserve.mdx @@ -0,0 +1,98 @@ +--- +title: etxn_reserve +description: Estimate the required fee for a txn to be emitted successfully +--- +import { Tabs, TabItem, LinkButton } from '@astrojs/starlight/components'; + +### Concepts + +Emitted Transactions + +### Behaviour + +* Specifies a number of emitted transactions this hook might emit during execution. + +### Definition + + + +```c +int64_t etxn_fee_base ( + uint32_t count +); +``` + + + + + +```javascript +function etxn_reserve(count: number): ErrorCode | number +``` + + + + + +### Example + + + +```c +etxn_reserve(2); +``` + + + + + +```javascript +etxn_reserve(2) +``` + + + + + +### Parameters + + + +| Name | Type | Description | +| ----- | --------- | ------------------------------------------------------------------------------------------- | +| count | uint32_t | The largest number of transactions this hook might emit during the course of one execution. | + + + + + + + +| Name | Type | Description | +| ----- | ------ | ---------------------------------------------------------------- | +| count | number | The maximum amount of transactions this Hook is allowed to emit. | + + + + + +### Return Code + + + +| Type | Description | +| -------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| int64_t |

The maximum number of emitted transactions this hook may emit. This will always be the same as the count parameter or an error as below.

If negative, an error:
ALREADY_SET
- The hook already called this function earlier.

TOO_BIG
- The specified number of emitted transactions is too large.

| + + + + + + + +| Type | Description | +| ------ | ---------------------------------------------------------------------------------- | +| number | An ErrorCode if there is an error, or the configured transaction count on success. | + + + diff --git a/src/content/docs/br/docs/hooks/functions/float/float_compare.mdx b/src/content/docs/br/docs/hooks/functions/float/float_compare.mdx new file mode 100644 index 0000000..b68a249 --- /dev/null +++ b/src/content/docs/br/docs/hooks/functions/float/float_compare.mdx @@ -0,0 +1,128 @@ +--- +title: float_compare +description: Perform a comparison on two XFL floating point numbers +--- +import { Tabs, TabItem, LinkButton, Aside } from '@astrojs/starlight/components'; + +### Concepts + +Floating Point Numbers (XFL) + +### Behaviour + + + +* Evaluate a comparison of two XFL floating point numbers +* Return the result of the comparison as a boolean encoded in an int64_t. + + + +* Evaluate a comparison of two XFL floating point numbers +* Returns an error code or the comparison result as a number. + + + + + +### Definition + + + +```c +int64_t float_compare ( + int64_t float1, + int64_t float2, + uint32_t mode +); +``` + + + +```javascript +function float_compare( + f1: bigint, + f2: bigint, + mode: number + ): ErrorCode | number +``` + + + + + +### Example + + + +```c +if (float_compare(pusd_to_send, 0, COMPARE_LESS) == 1) +{ + // pusd_to_send is less than 0 +} +``` + + + + + +```javascript +if (float_compare(pusd_to_send, 0n, COMPARE_LESS) == 1) +{ + // pusd_to_send is less than 0 +} +``` + + + + + +### Parameters + + + + + +| Name | Type | Description | +| ------ | --------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| float1 | int64_t | An XFL floating point enclosing number representing the first operand to the comparison | +| float2 | int64_t | An XFL floating point enclosing number representing the second operand to the comparison | +| mode | uint32_t | A bit-flag field consisting of any of (or any logically valid combination of) the following flags:
COMPARE_EQUAL `1`
COMPARE_LESS `2`
COMPARE_GREATER `4`

Valid combinations are:
COMPARE_LESS \| COMPARE_GREATER
- Not equal

COMPARE_LESS \| COMPARE_EQUAL
- Less than or equal to

COMPARE_GREATER \| COMPARE_EQUAL
- Greater than or equal to | + + + + + + + +| Name | Type | Description | +| ---- | ------ | -------------------------------------------------------------- | +| f1 | bigint | The first float to compare. | +| f2 | bigint | The second float to compare. | +| mode | number | The comparison mode (e.g., less than, equal to, greater than). | + + + + + +### Return Code + + + + + +| Type | Description | +| -------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| int64_t | 0 if the comparison was logically false.
1 if the comparison was logically true.

If negative, an error:
INVALID_FLOAT
- one of the supplied parameters was not a valid XFL enclosing number

INVALID_ARGUMENT
- invalid combination of supplied comparison flags. | + + + + + +| Type | Description | +| ------------------- | ----------------------------------------------------------- | +| ErrorCode or number | Returns an error code or the comparison result as a number. | + + + diff --git a/src/content/docs/br/docs/hooks/functions/float/float_divide.mdx b/src/content/docs/br/docs/hooks/functions/float/float_divide.mdx new file mode 100644 index 0000000..06e9ae7 --- /dev/null +++ b/src/content/docs/br/docs/hooks/functions/float/float_divide.mdx @@ -0,0 +1,103 @@ +--- +title: float_divide +description: Divide an XFL by another XFL floating point number +--- +import { Tabs, TabItem, LinkButton } from '@astrojs/starlight/components'; + +### Concepts + +Floating Point Numbers (XFL) + +### Behaviour + + + +* Divide an XFL by another XFL +* Return a new XFL as an int64_t + + + +* Divides one float representation by another. +* An error code or the quotient as a bigint. + + + + + +### Definition + + + +```c +int64_t float_divide ( + int64_t float1, + int64_t float2 +); +``` + + + +```javascript + function float_divide(f1: bigint, f2: bigint): ErrorCode | bigint +``` + + + + + +### Example + + + +```c +int64_t still_one = + float_divide(float_one(), float_one()); +``` + + + +```javascript +const still_one = + float_divide(float_one(), float_one()) +``` + + + + + +### Parameters + + + +| Name | Type | Description | +| ------ | -------- | ------------------------------------------------------------ | +| float1 | int64_t | An XFL floating point enclosing number to act as numerator | +| float2 | int64_t | An XFL floating point enclosing number to act as denominator | + + + +| Name | Type | Description | +| ---- | ------ | ------------------- | +| f1 | bigint | The dividend float. | +| f2 | bigint | The divisor float. | + + + + + +### Return Code + + + +| Type | Description | +| -------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| int64_t |

The XFL (xls17) enclosing number

If negative, an error:
INVALID_FLOAT
- the supplied parameter was not a valid XFL enclosing number or the division resulted in an XFL that cannot be represented.

DIVISION_BY_ZERO
- the supplied parameter was zero.

| + + + +| Type | Description | +| ------------------- | ------------------------------------------ | +| bigint or ErrorCode | An error code or the quotient as a bigint. | + + + diff --git a/src/content/docs/br/docs/hooks/functions/float/float_exponent.mdx b/src/content/docs/br/docs/hooks/functions/float/float_exponent.mdx new file mode 100644 index 0000000..872595a --- /dev/null +++ b/src/content/docs/br/docs/hooks/functions/float/float_exponent.mdx @@ -0,0 +1,77 @@ +--- +title: float_exponent +description: Get the exponent of an XFL enclosing number +--- +import { Tabs, TabItem, LinkButton, Aside } from '@astrojs/starlight/components'; + + + + + + + + + +### Concepts + +Floating Point Numbers (XFL) + +### Behaviour + + + +* Return the exponent part of an XFL as a signed integer + + + + + + + +### Definition + + + +Because exponents can be negative, and because negatives are reserved for error states, exponents cannot be returned from functions. Therefore this function has become a macro as shown below. + +```c +#define float_exponent(f)\ + (((int32_t)(((f) >> 54U) & 0xFFU)) - 97) +``` + + + +```javascript +const float_exponent = (f) => (Number(((f) >> 54n) & 0xFFn) - 97) +``` + + + + + +### Example + + + +```c +int64_t exponent = + float_exponent(float_one()); +``` + + + + + +### Parameters + + + +| Name | Type | Description | +| ------ | -------- | -------------------------------------- | +| float1 | int64_t | An XFL floating point enclosing number | + + + diff --git a/src/content/docs/br/docs/hooks/functions/float/float_int.mdx b/src/content/docs/br/docs/hooks/functions/float/float_int.mdx new file mode 100644 index 0000000..1a40437 --- /dev/null +++ b/src/content/docs/br/docs/hooks/functions/float/float_int.mdx @@ -0,0 +1,117 @@ +--- +title: float_int +description: Convert an XFL floating point into an integer (floor) +--- +import { Tabs, TabItem, LinkButton, Aside } from '@astrojs/starlight/components'; + +### Concepts + +Floating Point Numbers (XFL) + +### Behaviour + + + +* Left shift (multiply by 10) the XFL by the number of specified decimal places +* Convert the resulting XFL to an integer, discarding any remainder +* Return the integer + + + +* Converts a float representation to an integer with specified decimal places. +* An error code or the resulting integer as a number. + + + +### Definition + + + +```c +int64_t float_int ( + int64_t float1, + uint32_t decimal_places, + uint32_t absolute +); +``` + + + +```javascript +function float_int( + f1: bigint, + decimal_places: number, + abs: number + ): ErrorCode | number +``` + + + + + +### Example + + + +```c +int64_t drops = + float_int(xahbalance, 6, 0); +``` + + + +```javascript +const drops = + float_int(xahbalance, 6, 0); +``` + + + + + +### Parameters + + + +| Name | Type | Description | +| --------------- | --------- | -------------------------------------------------------------------------------------------------------- | +| float1 | int64_t | An XFL floating point enclosing number representing the first operand to the addition | +| decimal_places | uint32_t | The number of places to shift the decimal to the right before computing the floor of the floating point. | +| absolute | uint32_t | If `1` also take the absolute of the value before returning it. | + + + + + + + +| Name | Type | Description | +| --------------- | ------ | --------------------------------------------- | +| f1 | bigint | The float to convert | +| decimal_places | number | The number of decimal places to consider. | +| abs | number | Indicates whether to take the absolute value. | + + + + + +### Return Code + + + +| Type | Description | +| -------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| int64_t |

The computed positive integer

If negative, an error:
INVALID_FLOAT
- one of the supplied parameters was not a valid XFL enclosing number

INVALID_ARGUMENT
- attempted to specify more than 15 decimal places.

CANT_RETURN_NEGATIVE
- attempted to return a negative integer but this is not allowed, use absolute = 1

| + + + + + +| Type | Description | +| ------------------- | ----------------------------------------------------------- | +| number or ErrorCode | Returns an error code or the resulting integer as a number. | + + + diff --git a/src/content/docs/br/docs/hooks/functions/float/float_invert.mdx b/src/content/docs/br/docs/hooks/functions/float/float_invert.mdx new file mode 100644 index 0000000..4b8f61e --- /dev/null +++ b/src/content/docs/br/docs/hooks/functions/float/float_invert.mdx @@ -0,0 +1,102 @@ +--- +title: float_invert +description: Divide one by an XFL floating point number +--- +import { Tabs, TabItem, LinkButton } from '@astrojs/starlight/components'; + +### Concepts + +Floating Point Numbers (XFL) + +### Behaviour + + + +* Inverts a float representation. +* Return a inverted float as a bigint or an ErrorCode + + + +* Divide `1` by an XFL +* Return a new XFL as an int64_t + + + + + +### Definition + + + +```c +int64_t float_invert ( + int64_t float1 +); +``` + + + + + +```javascript +function float_invert(f1: bigint): ErrorCode | bigint +``` + + + + + +### Example + + + +```c +int64_t still_one = + float_invert(float_one()); +``` + + + +```javascript +const still_one = + float_invert(float_one()) +``` + + + + + +### Parameters + + + +| Name | Type | Description | +| ------ | -------- | -------------------------------------- | +| float1 | int64_t | An XFL floating point enclosing number | + + + +| Name | Type | Description | +| ---- | ----- | ------------------- | +| f1 | float | The float to invert | + + + + + +### Return Code + + + +| Type | Description | +| -------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| int64_t |

The XFL (xls17) enclosing number

If negative, an error:
INVALID_FLOAT
- the supplied parameter was not a valid XFL enclosing number or the division resulted in an XFL that cannot be represented.

DIVISION_BY_ZERO
- the supplied parameter was zero.

| + + + +| Type | Description | +| ------------------- | ------------------------------------------------ | +| ErrorCode \| bigint | An error code or the inverted float as a bigint. | + + + diff --git a/src/content/docs/br/docs/hooks/functions/float/float_log.mdx b/src/content/docs/br/docs/hooks/functions/float/float_log.mdx new file mode 100644 index 0000000..35b47dd --- /dev/null +++ b/src/content/docs/br/docs/hooks/functions/float/float_log.mdx @@ -0,0 +1,112 @@ +--- +title: float_log +description: Compute the decimal log of an XFL +--- +import { Tabs, TabItem, LinkButton, Aside } from '@astrojs/starlight/components'; + +### Concepts + +Floating Point Numbers (XFL) + +### Behaviour + + + +* Compute a the decimal logarithm of an XFL number +* Return the new XFL + + + + + +* Calculates the logarithm of a float representation. +* Returns an error code or the logarithm as a bigint. + + + + + + + +### Definition + + + +```c +int64_t float_log ( + int64_t float1 +); +``` + + + +```javascript +function float_log(f1: bigint): ErrorCode | bigint +``` + + + + + +### Example + + + +```c +int64_t zero = + float_log(float_one()); +``` + + + + + +```javascript +const zero = + float_log(float_one()) +``` + + + + + +### Parameters + + + + + +| Name | Type | Description | +| ------ | -------- | ------------------------------------------------------------------------------------------------------ | +| float1 | int64_t | An XFL floating point enclosing number representing the floating point number to take the logarithm of | + + + + + +| Name | Type | Description | +| ---- | ------ | ---------------------------------------- | +| f1 | bigint | The float to calculate the logarithm of. | + + + +### Return Code + + + +| Type | Description | +| -------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| int64_t |

The computed logarithm

If negative, an error:
INVALID_FLOAT
- the supplied parameter was not a valid XFL enclosing number

COMPLEX_NOT_SUPPORTED
- the supplied parameter was a negative number which would result in a complex return value.

| + + + +| Type | Description | +| ------------------- | --------------------------------------------------- | +| bigint or ErrorCode | Returns an error code or the logarithm as a bigint. | + + + diff --git a/src/content/docs/br/docs/hooks/functions/float/float_mantissa.mdx b/src/content/docs/br/docs/hooks/functions/float/float_mantissa.mdx new file mode 100644 index 0000000..ebd392c --- /dev/null +++ b/src/content/docs/br/docs/hooks/functions/float/float_mantissa.mdx @@ -0,0 +1,103 @@ +--- +title: float_mantissa +description: Get the mantissa of an XFL enclosing number +--- +import { Tabs, TabItem, LinkButton, Aside } from '@astrojs/starlight/components'; + +### Concepts + +Floating Point Numbers (XFL) + +### Behaviour + + + +* Return the mantissa part of an XFL as an unsigned integer + + + +* Retrieves the mantissa of a float representation. +* An error code or the mantissa as a bigint. + + + + + +### Definition + + + +```c +int64_t float_mantissa ( + int64_t float1 +); +``` + + + +```javascript +function float_mantissa(f1: bigint): ErrorCode | bigint +``` + + + + + +### Example + + + +```c +int64_t mantissa = + float_mantissa(float_one()); +``` + + + + + +```javascript +const mantissa = + float_mantissa(float_one()); +``` + + + + + +### Parameters + + + +| Name | Type | Description | +| ---- | ------ | ---------------------------------------- | +| f1 | bigint | The float to retrieve the mantissa from. | + + + +| Name | Type | Description | +| ------ | -------- | -------------------------------------- | +| float1 | int64_t | An XFL floating point enclosing number | + + + + + +### Return Code + + + +| Type | Description | +| -------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | +| int64_t |

The mantissa of the XFL

If negative, an error:
INVALID_FLOAT
- the supplied parameter was not a valid XFL enclosing number

| + + + +| Type | Description | +| ------------------- | ------------------------------------------ | +| bigint or ErrorCode | An error code or the mantissa as a bigint. | + + + diff --git a/src/content/docs/br/docs/hooks/functions/float/float_mulratio.mdx b/src/content/docs/br/docs/hooks/functions/float/float_mulratio.mdx new file mode 100644 index 0000000..215ff4a --- /dev/null +++ b/src/content/docs/br/docs/hooks/functions/float/float_mulratio.mdx @@ -0,0 +1,124 @@ +--- +title: float_mulratio +description: Multiply an XFL floating point by a non-XFL numerator and denominator +--- +import { Tabs, TabItem, LinkButton, Aside } from '@astrojs/starlight/components'; + +### Concepts + +Floating Point Numbers (XFL) + +### Behaviour + + + +* Compute the multiplication of an XFL (xls17) floating point number and the quotient of two integers +* Return a new XFL as an int64_t + + + +* Multiplies a float by a ratio defined by a numerator and denominator. +* Returns an error code or new XFL as a bigint. + + + +### Definition + + + +```c +int64_t float_mulratio ( + int64_t float1, + uint32_t round_up, + uint32_t numerator, + uint32_t denominator +); +``` + + + +```javascript +function float_mulratio( + f1: bigint, + round_up: number, + numerator: number, + denominator: number + ): ErrorCode | bigint +``` + + + + + +### Example + + + +```c +int64_t max_vault_pusd = + float_mulratio(max_vault_pusd, 0, + COLLATERALIZATION_NUMERATOR, COLLATERALIZATION_DENOMINATOR); +``` + + + +```javascript +const max_vault_pusd = + float_mulratio(max_vault_pusd, 0, + COLLATERALIZATION_NUMERATOR, COLLATERALIZATION_DENOMINATOR); +``` + + + + + +### Parameters + + + +| Name | Type | Description | +| ----------- | --------- | ------------------------------------------------------------------------------------------- | +| float1 | int64_t | An XFL floating point enclosing number representing the first operand to the multiplication | +| round_up | uint32_t | If non-zero all computations will be rounded up | +| numerator | uint32_t | The numerator of the quotient that the float will be multiplied by | +| denominator | uint32_t | The denominator of the quotient that the float will be multiplied by | + + + + + + + +| Name | Type | Description | +| ----------- | ------ | ------------------------------------------------------------------------------------------- | +| f1 | bigint | An XFL floating point enclosing number representing the first operand to the multiplication | +| round_up | number | If non-zero all computations will be rounded up | +| numerator | number | The numerator of the quotient that the float will be multiplied by | +| denominator | number | The denominator of the quotient that the float will be multiplied by | + + + + + +### Return Code + + + +| Type | Description | +| -------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| int64_t |

The XFL (xls17) enclosing number

If negative, an error:
INVALID_FLOAT
- one of the supplied parameters was not a valid XFL enclosing number

OVERFLOW
- the result of the multiplication was too large to store in an XFL.

DIVISION_BY_ZERO
- the supplied denominator was zero.

| + + + + + + + +| Type | Description | +| ------------------- | ----------------------------------------------------------- | +| ErrorCode or bigint | Returns an error code or tThe XFL (xls17) enclosing number. | + + + diff --git a/src/content/docs/br/docs/hooks/functions/float/float_multiply.mdx b/src/content/docs/br/docs/hooks/functions/float/float_multiply.mdx new file mode 100644 index 0000000..7599f89 --- /dev/null +++ b/src/content/docs/br/docs/hooks/functions/float/float_multiply.mdx @@ -0,0 +1,117 @@ +--- +title: float_multiply +description: Multiply two XFL numbers together +--- +import { Tabs, TabItem, LinkButton, Aside } from '@astrojs/starlight/components'; + +### Concepts + +Floating Point Numbers (XFL) + +### Behaviour + + + +* Compute the multiplication of two XFL (xls17) floating point numbers +* Return a new XFL as an int64_t + + + +* Compute the multiplication of two XFL (xls17) floating point numbers +* Return n error code or new XFL as a bigint. + + + + + +### Definition + + + +```c +int64_t float_multiply ( + int64_t float1, + int64_t float2 +); +``` + + + + + +```javascript +function float_multiply(f1: bigint, f2: bigint): ErrorCode | bigint +``` + + + + + +### Example + + + +```c +int64_t max_vault_pusd = + float_multiply(vault_xrp, exchange_rate); +``` + + + + + +```javascript +const max_vault_pusd = + float_multiply(vault_xrp, exchange_rate) +``` + + + + + +### Parameters + + + + + +| Name | Type | Description | +| ------ | -------- | -------------------------------------------------------------------------------------------- | +| float1 | int64_t | An XFL floating point enclosing number representing the first operand to the multiplication | +| float2 | int64_t | An XFL floating point enclosing number representing the second operand to the multiplication | + + + + + +| Name | Type | Description | +| ---- | ------ | -------------------------------------------------------------------------------------------- | +| f1 | bigint | An XFL floating point enclosing number representing the first operand to the multiplication | +| f2 | bigint | An XFL floating point enclosing number representing the second operand to the multiplication | + + + + + +### Return Code + + + + + +| Type | Description | +| -------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| int64_t |

The XFL (xls17) enclosing number

If negative, an error:
INVALID_FLOAT
- one of the supplied parameters was not a valid XFL enclosing number

OVERFLOW
- the result of the multiplication was too large to store in an XFL.

| + + + + + +| Type | Description | +| ------------------ | ------------------------------------------------- | +| Errorcor or bigint | An error code or The XFL (xls17) enclosing number | + + + diff --git a/src/content/docs/br/docs/hooks/functions/float/float_negate.mdx b/src/content/docs/br/docs/hooks/functions/float/float_negate.mdx new file mode 100644 index 0000000..c9173ea --- /dev/null +++ b/src/content/docs/br/docs/hooks/functions/float/float_negate.mdx @@ -0,0 +1,110 @@ +--- +title: float_negate +description: Negate an XFL floating point number +--- +import { Tabs, TabItem, LinkButton, Aside } from '@astrojs/starlight/components'; + +### Concepts + +Floating Point Numbers (XFL) + +### Behaviour + + + +* Multiply an XFL by `-1` +* Return a new XFL as an int64_t + + + +* Negates a float representation. +* Returns an error code or the negated float as a bigint. + + + +### Definition + + + +```c +int64_t float_negate ( + int64_t float1 +); +``` + + + + + +```javascript +function float_negate(f1: bigint): ErrorCode | bigint +``` + + + + + +### Example + + + +```c +int64_t negative_one = + float_negate(float_one()); +``` + + + + + +```javascript +const negative_one = + float_negate(float_one()); +``` + + + + + +### Parameters + + + +| Name | Type | Description | +| ------ | -------- | -------------------------------------- | +| float1 | int64_t | An XFL floating point enclosing number | + + + + + + + +| Name | Type | Description | +| ---- | ------ | -------------------- | +| f1 | bigint | The float to negate. | + + + + + +### Return Code + + + +| Type | Description | +| -------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| int64_t |

The XFL (xls17) enclosing number

If negative, an error:
INVALID_FLOAT
- one of the supplied parameters was not a valid XFL enclosing number

| + + + + + +| Type | Description | +| ------------------- | -------------------------------------------------- | +| ErrorCode or bigint | An error code or The XFL (xls17) enclosing number. | + + + diff --git a/src/content/docs/br/docs/hooks/functions/float/float_one.mdx b/src/content/docs/br/docs/hooks/functions/float/float_one.mdx new file mode 100644 index 0000000..7851a32 --- /dev/null +++ b/src/content/docs/br/docs/hooks/functions/float/float_one.mdx @@ -0,0 +1,83 @@ +--- +title: float_one +description: Return the number 1 represented in an XFL enclosing number +--- +import { Tabs, TabItem, LinkButton } from '@astrojs/starlight/components'; + +### Concepts + +Floating Point Numbers (XFL) + +### Behaviour + + + +* Return one(`1`) as an XFL int64_t + + + +* Retrieves the float representation of a number. + + + + + +### Definition + + + +```c +int64_t float_one(); +``` + + + +```javascript +function float_one(): ErrorCode | bigint +``` + + + + + +### Example + + + +```c +int64_t one = + float_one(); +``` + + + + + +```javascript +const one = float_one() +``` + + + + + +### Parameters + +This function has no parameters. + +### Return Code + + + +| Type | Description | +| -------- | -------------------------------- | +| int64_t | The XFL (xls17) enclosing number | + + + +| Type | Description | +| ------------------- | -------------------------------- | +| ErrorCode \| bigint | The XFL (xls17) enclosing number | + + + diff --git a/src/content/docs/br/docs/hooks/functions/float/float_root.mdx b/src/content/docs/br/docs/hooks/functions/float/float_root.mdx new file mode 100644 index 0000000..12311f0 --- /dev/null +++ b/src/content/docs/br/docs/hooks/functions/float/float_root.mdx @@ -0,0 +1,117 @@ +--- +title: float_root +description: Compute the nth root of an XFL +--- +import { Tabs, TabItem, LinkButton, Aside } from '@astrojs/starlight/components'; + +### Concepts + +Floating Point Numbers (XFL) + +### Behaviour + + + +* Compute a the `nth` root of an XFL number +* Return the new XFL + + + + + +* Calculates the nth root of a float representation. +* An error code or the resulting root as a bigint. + + + + + +### Definition + + + +```c +int64_t float_root ( + int64_t float1, + uint32_t n +); +``` + + + + + +```javascript +function float_root(f1: bigint, n: number): ErrorCode | bigint +``` + + + + + +### Example + + + +```c +int64_t three = + float_root(nine, 2); +``` + + + + + +```javascript +const three = + float_root(nine, 2) +``` + + + + + +### Parameters + + + +| Name | Type | Description | +| ------ | --------- | -------------------------------------------------------------------------------------------------------- | +| float1 | int64_t | An XFL floating point enclosing number representing the floating point number to take the square root of | +| n | uint32_t | The root to compute, for example `2` is a square root. | + + + +| Name | Type | Description | +| ---- | ------ | ------------------------------------ | +| f1 | bigint | The float to calculate the root of. | +| n | number | The degree of the root to calculate. | + + + + + +### Return Code + + + + + +| Type | Description | +| -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| int64_t |

The computed nth root

If negative, an error:
INVALID_FLOAT
- the supplied parameter was not a valid XFL enclosing number

COMPLEX_NOT_SUPPORTED
- the supplied parameter was a negative number which would result in a complex root.

| + + + + + +| Type | Description | +| ------------------- | -------------------------------------------------------- | +| bigint or ErrorCode | Returns an error code or the resulting root as a bigint. | + + + diff --git a/src/content/docs/br/docs/hooks/functions/float/float_set.mdx b/src/content/docs/br/docs/hooks/functions/float/float_set.mdx new file mode 100644 index 0000000..1593e31 --- /dev/null +++ b/src/content/docs/br/docs/hooks/functions/float/float_set.mdx @@ -0,0 +1,120 @@ +--- +title: float_set +description: Create a float from an exponent and mantissa +--- +import { Tabs, TabItem, LinkButton, Aside } from '@astrojs/starlight/components'; + +### Concepts + +Floating Point Numbers (XFL) + +### Behaviour + + + +* Compute an XFL (xls17) floating point from the provided exponent and mantissa +* Return that XFL as an int64_t + + + +* Sets the exponent and mantissa for a float representation. +* Returns an error code or a new XFL as a bigint. + + + + + +### Definition + + + +```c +int64_t float_set ( + int32_t exponent, + int64_t mantissa +); +``` + + + + + +```javascript +function float_set(exponent: number, mantissa: number): ErrorCode | bigint +``` + + + + + +### Example + + + +```c +int64_t small_amount = + float_set(-81, 1); +``` + + + + + +```javascript +const small_amount = float_set(-81, 1); +``` + + + + + +### Parameters + + + +| Name | Type | Description | +| -------- | -------- | --------------------------------------------------------------- | +| exponent | int32_t | An exponent in the range `-96` to `80` | +| mantissa | int64_t | A mantissa. If negative then the sign of the float is negative. | + + + + + + + + + +| Name | Type | Description | +| -------- | ------ | --------------------------------------------------------------- | +| exponent | bigint | An exponent in the range `-96` to `80` | +| mantissa | bigint | A mantissa. If negative then the sign of the float is negative. | + + + + + +### Return Code + + + +| Type | Description | +| -------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| int64_t |

The XFL (xls17) enclosing number

If negative, an error:
INVALID_FLOAT
- The adjustment of the mantissa to 16 digits produced an under or overflow.

| + + + + + + + +| Type | Description | +| ------------------- | -------------------------------------------------- | +| ErrorCode \| bigint | An error code or the XFL (xls17) enclosing number. | + + + diff --git a/src/content/docs/br/docs/hooks/functions/float/float_sign.mdx b/src/content/docs/br/docs/hooks/functions/float/float_sign.mdx new file mode 100644 index 0000000..3e19503 --- /dev/null +++ b/src/content/docs/br/docs/hooks/functions/float/float_sign.mdx @@ -0,0 +1,102 @@ +--- +title: float_sign +description: Get the sign of an XFL enclosing number +--- +import { Tabs, TabItem, LinkButton, Aside } from '@astrojs/starlight/components'; + +### Concepts + +Floating Point Numbers (XFL) + +### Behaviour + + + +* Return `1` if the XFL is negative, otherwise return 0 + + + +* Return 1 if the XFL is negative, otherwise return 0 + + + +### Definition + + + +```c +int64_t float_sign ( + int64_t float1 +); +``` + + + +```javascript +function float_sign(f1: bigint): ErrorCode | number +``` + + + + + +### Example + + + +```c +int64_t sign = + float_sign(float_one()); +``` + + + + + +```javascript +const sign = + float_sign(float_one()); +``` + + + + + +### Parameters + + + +| Name | Type | Description | +| ------ | -------- | -------------------------------------- | +| float1 | int64_t | An XFL floating point enclosing number | + + + +| Name | Type | Description | +| ---- | ------ | ---------------------------------------- | +| f1 | bigint | The float to retrieve the mantissa from. | + + + + + +### Return Code + + + +| Type | Description | +| -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| int64_t |

The sign of the XFL:
0 if positive, 1 if negative.

If negative, an error:
INVALID_FLOAT
- the supplied parameter was not a valid XFL enclosing number

| + + + + + +| Type | Description | +| ------------------- | ------------------------------------------ | +| bigint or ErrorCode | An error code or the mantissa as a bigint. | + + + diff --git a/src/content/docs/br/docs/hooks/functions/float/float_sto.mdx b/src/content/docs/br/docs/hooks/functions/float/float_sto.mdx new file mode 100644 index 0000000..b5cf1a8 --- /dev/null +++ b/src/content/docs/br/docs/hooks/functions/float/float_sto.mdx @@ -0,0 +1,139 @@ +--- +title: float_sto +description: Output an XFL as a serialized object +--- +import { Tabs, TabItem, LinkButton, Aside } from '@astrojs/starlight/components'; + +### Concepts + +Floating Point Numbers (XFL) +Serialized Objects + +### Behaviour + + + +* Read an XFL floating point number and optionally a field code and currency code +* Write a serialized amount to `write_ptr` according to the parameters provided + + + +* Stores a float representation into a specified field. +* Returns an error code or the updated value as an array of numbers. + + + +### Definition + + + +```c +int64_t float_sto ( + uint32_t write_ptr, + uint32_t write_len, + uint32_t cread_ptr, + uint32_t cread_len, + uint32_t iread_ptr, + uint32_t iread_len, + int64_t float1, + uint32_t field_code +); +``` + + + + + +```javascript +function float_sto( + currency: ByteArray | HexString | undefined, + issuer: ByteArray | HexString | undefined, + f1: bigint, + field_code: number + ): ErrorCode | ByteArray +``` + + + + + +### Example + + + +```c +#define SBUF(str) (uint32_t)(str), sizeof(str) +uint8_t amt_out[48]; +if (float_sto(SBUF(amt_out), + SBUF(currency), SBUF(hook_accid), pusd_to_send, -1) < 0) + rollback(SBUF("Peggy: Could not dump pusd amount into sto"), 1); +``` + + + + + +```javascript +const amt_out = float_sto(currency, hook_accid, pusd_to_send, -1) +if (typeof amt_out === 'number') + rollback("Peggy: Could not dump pusd amount into sto", 1) +``` + + + + + +### Parameters + + + +| Name | Type | Description | +| ----------- | --------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| write_ptr | uint32_t | Pointer to a buffer of a suitable size to store the serialized amount field. Recommend at least 48 bytes. | +| write_len | uint32_t | The length of the output buffer. | +| cread_ptr | uint32_t | Pointer to a buffer contianing the currency code to serialize into the output. _May be null._ | +| cread_len | uint32_t | The length of the currency code. This must be 20 or 3 or 0 (null). | +| iread_ptr | uint32_t | Pointer to a buffer containing the issuer's Account ID to serialize into the output. _May be null._ | +| iread_len | uint32_t | The length of the issuer's Account ID. This must be either 20 or 0 (null). | +| float1 | int64_t | An XFL floating point enclosing number to serialize. | +| field_code | uint32_t |

The sf field code to prefix the serialized amount with. E.g. sfAmount.
If this field is 0xFFFFFFFFU (i.e. (uint32_t)(-1)) then no field code is prepended to the output, and no issuer or currency code is appended, but serialization proceeds as a floating point amount.
If this field is 0 no field code is prepended to the output, and no issuer or currency code is appended, but serialization proceeds as though the amount is an XRP native amount rather than a floating point.

| + + + + + + + +| Name | Type | Description | +| ----------- | ----------------------------------- | ---------------------------------------------------------- | +| currency | ByteArray \| HexString \| undefined | The current value to store into. | +| issuer | ByteArray \| HexString \| undefined | The value to store. | +| f1 | bigint | The field code indicating where to store the float. | +| field_code | number | An error code or the updated value as an array of numbers. | + + + + + +### Return Code + + + +| Type | Description | +| -------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| int64_t |

The number of bytes written to the output buffer.

If negative, an error:
INVALID_FLOAT
- the supplied float was not a valid XFL enclosing number

OUT_OF_BOUNDS
- pointers/lengths specified outside of hook memory.

INVALID_ARGUMENT
- If instructed to output as XRP or without field code then all non-write pointers and lengths should be 0 (null).

TOO_SMALL
- The output buffer was too small to receive the serialized object.

XFL_OVERFLOW
- Expressing the output caused an overflow during normalization.

| + + + + + + + +| Type | Description | +| ---------------------- | ------------------------------------------------------------------ | +| ErrorCode \| ByteArray | Returns an error code or the updated value as an array of numbers. | + + + diff --git a/src/content/docs/br/docs/hooks/functions/float/float_sto_set.mdx b/src/content/docs/br/docs/hooks/functions/float/float_sto_set.mdx new file mode 100644 index 0000000..79cfd20 --- /dev/null +++ b/src/content/docs/br/docs/hooks/functions/float/float_sto_set.mdx @@ -0,0 +1,110 @@ +--- +title: float_sto_set +description: Read a serialized amount into an XFL +--- +import { Tabs, TabItem, LinkButton } from '@astrojs/starlight/components'; + +### Concepts + +Floating Point Numbers (XFL) +Serialized Objects + +### Behaviour + + + +* Read a serialized floating point number. +* If there are more fields/data after the serialized floating pointer number then ignore them. +* Return it as an XFL enclosing number + + + +* Sets the buffer for storing float representations. +* Returns ErrorCode or the result as a number. + + + + + +### Definition + + + +```c +int64_t float_sto_set ( + uint32_t read_ptr, + uint32_t read_len +); +``` + + + +```javascript +function float_sto_set(buf: ByteArray | HexString): ErrorCode | number +``` + + + + + +### Example + + + +```c +int64_t vault_pusd = float_sto_set(vault, 8); +if (vault_pusd < 0) + rollback("Failed to parse serialized float.", 33, 1); +``` + + + + + +```javascript +const vault_pusd = float_sto_set(vault) +if (typeof vault_pusd === 'string') + rollback("Failed to parse serialized float.", 1) +``` + + + + + +### Parameters + + + +| Name | Type | Description | +| --------- | --------- | ----------------------------------------------------------------- | +| read_ptr | uint32_t | Pointer to a buffer contianing the serialized XFL. _May be null._ | +| read_len | uint32_t | The length of the buffer. | + + + + + +| Name | Type | Description | +| ---- | ---------------------- | ------------------ | +| buf | ByteArray \| HexString | The buffer to set. | + + + + + +### Return Code + + + +| Type | Description | +| -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| int64_t |

The number of bytes written to the output buffer.

If negative, an error:
NOT_AN_OBJECT
- the supplied buffer did not contain a valid serialized floating point number

OUT_OF_BOUNDS
- pointers/lengths specified outside of hook memory.

| + + + +| Type | Description | +| ------------------- | ---------------------------------------- | +| ErrorCode or number | An error code or the result as a number. | + + + diff --git a/src/content/docs/br/docs/hooks/functions/float/float_sum.mdx b/src/content/docs/br/docs/hooks/functions/float/float_sum.mdx new file mode 100644 index 0000000..f2879f9 --- /dev/null +++ b/src/content/docs/br/docs/hooks/functions/float/float_sum.mdx @@ -0,0 +1,113 @@ +--- +title: float_sum +description: Add two XFL numbers together +--- +import { Tabs, TabItem, LinkButton, Aside } from '@astrojs/starlight/components'; + +### Concepts + +Floating Point Numbers (XFL) + +### Behaviour + + + +* Compute the addition of two XFL (xls17) floating point numbers +* Return a new XFL as an int64_t + + + +* Sums two float representations. +* Returns an error code or the sum as a bigint. + + + +### Definition + + + +```c +int64_t float_sum ( + int64_t float1, + int64_t float2 +); +``` + + + + + +```javascript +function float_sum(f1: bigint, f2: bigint): ErrorCode | bigint +``` + + + + + +### Example + + + +```c +int64_t two = + float_sum(float_one(), float_one()); +``` + + + + + +```javascript +const two = + float_sum(float_one(), float_one()); +``` + + + + + +### Parameters + + + + + +| Name | Type | Description | +| ------ | -------- | -------------------------------------------------------------------------------------- | +| float1 | int64_t | An XFL floating point enclosing number representing the first operand to the addition | +| float2 | int64_t | An XFL floating point enclosing number representing the second operand to the addition | + + + + + + + +| Name | Type | Description | +| ---- | ------ | ------------------------ | +| f1 | bigint | The first float to sum. | +| f2 | bigint | The second float to sum. | + + + + + +### Return Code + + + +| Type | Description | +| -------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| int64_t |

The XFL (xls17) enclosing number

If negative, an error:
INVALID_FLOAT
- one of the supplied parameters was not a valid XFL enclosing number

OVERFLOW
- the result of the addition was too large to store in an XFL.

| + + + +| Type | Description | +| ------------------- | ------------------------------------- | +| ErrorCode or bigint | An error code or the sum as a bigint. | + + + diff --git a/src/content/docs/br/docs/hooks/functions/hook-context/hook_account.mdx b/src/content/docs/br/docs/hooks/functions/hook-context/hook_account.mdx new file mode 100644 index 0000000..d361672 --- /dev/null +++ b/src/content/docs/br/docs/hooks/functions/hook-context/hook_account.mdx @@ -0,0 +1,94 @@ +--- +title: hook_account +description: Retreive the 20 byte Account ID the Hook is executing on +--- +import { Tabs, TabItem } from '@astrojs/starlight/components'; + +### Behaviour + + + +* Write the 20 byte Account ID to the write_ptr + + + +* Retrieve the 20 byte Account ID the Hook is executing on. + + + +### Definition + + + +```c +int64_t hook_account ( + uint32_t write_ptr, + uint32_t write_len +); +``` + + + +``JavaScript +function hook_account(): ErrorCode | ByteArray +``` + + + + + +### Example + + + +```c +uint8_t hook_acc_id[20]; +int64_t bytes_written = + hook_account(hook_acc_id, 20); +``` + + + + + +```javascript +const hook_acc_id =hook_account() +``` + + + + + +### Parameters + + + +| Name | Type | Description | +| ---------- | --------- | ---------------------------------------------------------------------------------------- | +| write_ptr | uint32_t | Pointer to a buffer of a suitable size to store the output. Should be at least 20 bytes. | +| write_len | uint32_t | Length of the output buffer. | + + + +No parameters + + + + + +### Return Code + + + +| Type | Description | +| -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ | +| int64_t |

The number of bytes written

If negative, an error:
OUT_OF_BOUNDS
- pointers/lengths specified outside of hook memory.

| + + + +| Type | Description | +| ---------------------- | ----------------------------------------------------------------------------------------- | +| ErrorCode or ByteArray | Returns the Account ID the Hook is executing on, or an error code if the retrieval fails. | + + + diff --git a/src/content/docs/br/docs/hooks/functions/hook-context/hook_again.mdx b/src/content/docs/br/docs/hooks/functions/hook-context/hook_again.mdx new file mode 100644 index 0000000..6723228 --- /dev/null +++ b/src/content/docs/br/docs/hooks/functions/hook-context/hook_again.mdx @@ -0,0 +1,57 @@ +--- +title: hook_again +description: Returns the position in the hook chain the currently executing hook occupies +--- +import { Tabs, TabItem } from '@astrojs/starlight/components'; + +### Behaviour + +* If the hook is being strongly executed then flag this specific hook in the chain for [Again As Weak Execution](/docs/hooks/concepts/weak-and-strong). +* If the originating transaction successfully is applied then the hook will be called again in a second, Weak Execution. + +### Definition + + + +```c +int64_t hook_again(void); +``` + + +```javascript +function hook_again(): ErrorCode | number +``` + + + +### Example + + + +```c +int64_t result = + hook_again(); +``` + + +```javascript +const result = hook_again() +``` + + + +### Parameters + +This API has no parameters + +### Return Code + + + +
TypeDescription
int64_t1 iff successfully flagged for Again As Weak.

PREREQUISITE_NOT_MET
- This hook is already being executed weakly at the time of the call.

ALREADY_SET
- The function was already called this execution.
+ + +
TypeDescription
numberReturns a status code indicating the result of the operation.
+ + + diff --git a/src/content/docs/br/docs/hooks/functions/hook-context/hook_hash.mdx b/src/content/docs/br/docs/hooks/functions/hook-context/hook_hash.mdx new file mode 100644 index 0000000..ae06336 --- /dev/null +++ b/src/content/docs/br/docs/hooks/functions/hook-context/hook_hash.mdx @@ -0,0 +1,91 @@ +--- +title: hook_hash +description: Retreive the 32 byte namespace biased SHA512H of the currently executing Hook +--- +import { Tabs, TabItem } from '@astrojs/starlight/components'; + +### Behaviour + + + +* Look up the hash of the hook installed on hook account at position `hook_no` +* Write the 32 byte hash to `write_ptr` + + +* Look up the hash of the hook installed on the hook account at the specified position. +* The Namespace biased SHA512H of the currently executing Hook, or an error code if the lookup fails. + + + + + +### Definition + + + +```c +int64_t hook_hash ( + uint32_t write_ptr, + uint32_t write_len, + int32_t hook_no +); +``` + + +```javascript +function hook_hash(hookno: number): ErrorCode | ByteArray +``` + + + +### Example + + + +```c +uint8_t hash[32]; +int64_t bytes_written = + hook_hash(hash, 32, -1); +``` + + +```javascript +const hash = hook_hash(hookno) +``` + + + +### Parameters + + + +| Name | Type | Description | +| ---------- | --------- | ---------------------------------------------------------------------------------------------- | +| write_ptr | uint32_t | Pointer to a buffer of a suitable size to store the output. Should be at least 32 bytes. | +| write_len | uint32_t | Length of the output buffer. | +| hook_no | int32_t | The position in the hook chain the hook is located at, or -1 for the currently executing hook. | + + +| Name | Type | Description | +| -------- | ------ | ---------------------------------------------------------------------------------------------- | +| hook_no | number | The position in the hook chain the hook is located at, or -1 for the currently executing hook. | + + + + + +### Return Code + + + +| Type | Description | +| -------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| int64_t |

The number of bytes written

If negative, an error:
OUT_OF_BOUNDS
- pointers/lengths specified outside of hook memory.

DOESNT_EXIST
- The specified hook sequence number doesn't exist in the hook chain.

| + + +| Type | Description | +| ---------------------- | ----------------------------------------------------------------------------------------------------------- | +| ByteArray or ErrorCode | Returns the Namespace biased SHA512H of the currently executing Hook, or an error code if the lookup fails. | + + + diff --git a/src/content/docs/br/docs/hooks/functions/hook-context/hook_param.mdx b/src/content/docs/br/docs/hooks/functions/hook-context/hook_param.mdx new file mode 100644 index 0000000..5f51e0f --- /dev/null +++ b/src/content/docs/br/docs/hooks/functions/hook-context/hook_param.mdx @@ -0,0 +1,110 @@ +--- +title: hook_param +description: Retrieve the parameter value for a named hook parameter +--- +import { Tabs, TabItem } from '@astrojs/starlight/components'; + +### Behaviour + + + +* Look up the value for a named parameter specified in `read_ptr` +* Write the parameter's value to `write_ptr` + + + +* Retrieve the value of a parameter associated with the specified key. +* Returns the value associated with the key, or an error code if the retrieval fails. + + + +### Definition + + + +```c +int64_t hook_param ( + uint32_t write_ptr, + uint32_t write_len, + uint32_t read_ptr, + uint32_t read_len +); +``` + + + +```javascript +function hook_param(key: ByteArray | HexString): ErrorCode | ByteArray +``` + + + + + +### Example + + + +```c +uint8_t pname[] = {0xCAU, 0xFEU}; +uint8_t pvalue[32]; +int64_t value_len = + hook_param(pvalue, 32, pname, 2); +``` + + + +```javascript +const pname = [0xCA, 0xFE] +const pvalue = hook_param(pname) +``` + + + + + +### Parameters + + + +| Name | Type | Description | +| ---------- | --------- | ---------------------------------------------------------------------------------------- | +| write_ptr | uint32_t | Pointer to a buffer of a suitable size to store the output. Should be at least 32 bytes. | +| write_len | uint32_t | Length of the output buffer. | +| read_ptr | uint32_t | Pointer to a buffer containing the parameter's name | +| read_len | uint32_t | Length of the parameter's name | + + + + + + + +| Name | Type | Description | +| ---- | ---------------------- | -------------------------------------------------- | +| key | ByteArray or HexString | The key for which to retrieve the parameter value. | + + + + + +### Return Code + + + +| Type | Description | +| -------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| int64_t |

The number of bytes written

If negative, an error:
OUT_OF_BOUNDS
- pointers/lengths specified outside of hook memory.

DOESNT_EXIST
- The specified paramater doesn't exist or is null

TOO_SMALL
- The parameter name can't be null

TOO_BIG
- The parameter name is greater than 32 bytes

| + + + + + + + +| Type | Description | +| ---------------------- | ----------------------------------------------------------------------------------- | +| ByteArray or ErrorCode | Returns the value associated with the key, or an error code if the retrieval fails. | + + + diff --git a/src/content/docs/br/docs/hooks/functions/hook-context/hook_param_set.mdx b/src/content/docs/br/docs/hooks/functions/hook-context/hook_param_set.mdx new file mode 100644 index 0000000..5f20681 --- /dev/null +++ b/src/content/docs/br/docs/hooks/functions/hook-context/hook_param_set.mdx @@ -0,0 +1,121 @@ +--- +title: hook_param_set +description: >- + Set or delete a parameter on a hook on the same account further down the + execution chain +--- +import { Tabs, TabItem } from '@astrojs/starlight/components'; + +### Behaviour + + + +* Search the hook chain on the hook account for a 32 byte hash indicated by `hread_ptr` +* If found: set a parameter: +* With the parameter name indicated by `kread_ptr` and +* The parameter value indicated by `read_ptr` + + + +* Set a parameter for the hook with the specified value and key, and associate it with a hash. +* Returns a status code indicating the result of the operation. + + + +### Definition + + + +```c +int64_t hook_param_set ( + uint32_t read_ptr, + uint32_t read_len, + uint32_t kread_ptr, + uint32_t kread_len, + uint32_t hread_ptr, + uint32_t hread_len +); +``` + + +```javascript +function hook_param_set( + val: ByteArray | HexString, + key: ByteArray | HexString, + hash: ByteArray | HexString + ): number +``` + + + +### Example + + + +```c +uint8_t pvalue[] = "some parameter value"; +uint8_t pname[] = "paramname"; +uint8_t phash[] = { 0x19U, 0xFEU, 0x69U, 0xF1U, 0x53U, 0x66U, 0x4EU, 0x8CU, + 0x97U, 0xF4U, 0x4CU, 0x5CU, 0x3CU, 0x65U, 0x63U, 0x79U, + 0xC2U, 0xD0U, 0x26U, 0xE7U, 0x90U, 0xEFU, 0x38U, 0xF7U, + 0xEDU, 0x73U, 0xE9U, 0xCEU, 0x9CU, 0x9DU, 0xBFU, 0x03U }; +int64_t result = + hook_param_set(pvalue, sizeof(pvalue), + pname, sizeof(pname), + phash, sizeof(phash)); +``` + + +```javascript +const pvalue = "some parameter value" +const pname = "paramname" +const phash = [ 0x19, 0xFE, 0x69, 0xF1, 0x53, 0x66, 0x4E, 0x8C, + 0x97, 0xF4, 0x4C, 0x5C, 0x3C, 0x65, 0x63, 0x79, + 0xC2, 0xD0, 0x26, 0xE7, 0x90, 0xEF, 0x38, 0xF7, + 0xED, 0x73, 0xE9, 0xCE, 0x9C, 0x9D, 0xBF, 0x03 ] +const result = hook_param_set(str2hex(pvalue), str2hex(pname), phash) +``` + + + +### Parameters + + + +| Name | Type | Description | +| ---------- | --------- | ------------------------------- | +| read_ptr | uint32_t | Pointer to parameter value | +| read_len | uint32_t | Length of the parameter value | +| kread_ptr | uint32_t | Pointer to the parameter name | +| kread_len | uint32_t | Length of the parameter name | +| hread_ptr | uint32_t | Pointer to hook hash | +| hread_len | uint32_t | Length of hook hash (always 32) | + + + +| Name | Type | Description | +| ---- | ---------------------- | ----------------------------------------- | +| val | ByteArray or HexString | The value to set for the parameter. | +| key | ByteArray or HexString | The key associated with the parameter. | +| hash | ByteArray or HexString | The hash to associate with the parameter. | + + + + + +### Return Code + + + + + +
TypeDescription
int64_tThe length of the parameter value successfully set

If negative, an error:
OUT_OF_BOUNDS
- pointers/lengths specified outside of hook memory.

TOO_SMALL
- The parameter name can't be null

TOO_BIG
- The parameter name is greater than 32 bytes
+ + + + + +
TypeDescription
numberReturns a status code indicating the result of the operation.
+ + + diff --git a/src/content/docs/br/docs/hooks/functions/hook-context/hook_pos.mdx b/src/content/docs/br/docs/hooks/functions/hook-context/hook_pos.mdx new file mode 100644 index 0000000..a2e6cdc --- /dev/null +++ b/src/content/docs/br/docs/hooks/functions/hook-context/hook_pos.mdx @@ -0,0 +1,60 @@ +--- +title: hook_pos +description: Returns the position in the hook chain the currently executing hook occupies +--- +import { Tabs, TabItem } from '@astrojs/starlight/components'; + +### Behaviour + +* Returns the position in the hook chain the currently executing hook occupies. + +### Definition + + + +```c +int64_t hook_pos(void); +``` + + +```javascript +hook_pos() +``` + + + +### Example + + + +```c +int64_t pos = + hook_pos(); +``` + + +```javascript +const pos = hook_pos() +``` + + + +### Parameters + +This API has no parameters + +### Return Code + + + +| Type | Description | +| -------- | ----------------------------------------------------------------------------------------- | +| int64_t | The position in the chain the currently executing hook occupies. The first position is 0. | + + +| Type | Description | +| ------ | ---------------------------------------------------------------------------------------- | +| number | Returns the current position in the hook chain, or an error code if the retrieval fails. | + + + diff --git a/src/content/docs/br/docs/hooks/functions/hook-context/hook_skip.mdx b/src/content/docs/br/docs/hooks/functions/hook-context/hook_skip.mdx new file mode 100644 index 0000000..ba19396 --- /dev/null +++ b/src/content/docs/br/docs/hooks/functions/hook-context/hook_skip.mdx @@ -0,0 +1,101 @@ +--- +title: hook_skip +description: Skip a hook that appears later in the hook chain on the hook account +--- +import { Tabs, TabItem } from '@astrojs/starlight/components'; + +### Behaviour + + + +* Search the hook chain for a hook identified by the hook hash at `read_ptr` +* Mark it as disabled for this chain execution + + + +* Skip the execution of a hook based on the provided hash and flag. +* Returns a status code indicating the result of the operation. + + + +### Definition + + + +```c +int64_t hook_skip ( + uint32_t read_ptr, + uint32_t read_len, + uint32_t flags +); +``` + + +```javascript +function hook_skip( + hash: ByteArray | HexString, + flag: number + ): ErrorCode | number +``` + + + +### Example + + + +```c +uint8_t phash[] = { 0x19U, 0xFEU, 0x69U, 0xF1U, 0x53U, 0x66U, 0x4EU, 0x8CU, + 0x97U, 0xF4U, 0x4CU, 0x5CU, 0x3CU, 0x65U, 0x63U, 0x79U, + 0xC2U, 0xD0U, 0x26U, 0xE7U, 0x90U, 0xEFU, 0x38U, 0xF7U, + 0xEDU, 0x73U, 0xE9U, 0xCEU, 0x9CU, 0x9DU, 0xBFU, 0x03U }; +int64_t result = + hook_skip(phash, 32, 0); +``` + + +```javascript +const phash = [ 0x19, 0xFE, 0x69, 0xF1, 0x53, 0x66, 0x4E, 0x8C, + 0x97, 0xF4, 0x4C, 0x5C, 0x3C, 0x65, 0x63, 0x79, + 0xC2, 0xD0, 0x26, 0xE7, 0x90, 0xEF, 0x38, 0xF7, + 0xED, 0x73, 0xE9, 0xCE, 0x9C, 0x9D, 0xBF, 0x03 ] +const result = hook_skip(phash, 0); +``` + + + +### Parameters + + + + + +| Name | Type | Description | +| --------- | --------- | ------------------------------------------------------------------------------------------------------------- | +| read_ptr | uint32_t | Pointer to a buffer containing the hook hash | +| read_len | uint32_t | Length of the hook hash (always 32) | +| flags | uint32_t |

If 0:
- add the hash to the hook skip list

If 1
- remove the hash from the hook skip list

| + + + + + +| Name | Type | Description | +| ---- | ---------------------- | --------------------------------------------------- | +| hash | ByteArray or HexString | The hash of the hook to skip. | +| flag | number | A flag indicating the reason for skipping the hook. | + + + +### Return Code + + + +
TypeDescription
int64_tIf successful 1

If negative, an error:
OUT_OF_BOUNDS
- pointers/lengths specified outside of hook memory.

DOESNT_EXIST
- The specified paramater doesn't exist or is null

INVALID_ARGUMENT
- Hash is not 32 bytes
+ + + +
TypeDescription
number or ErrorCodeReturns a status code indicating the result of the operation.
+ + + diff --git a/src/content/docs/br/docs/hooks/functions/ledger/fee_base.mdx b/src/content/docs/br/docs/hooks/functions/ledger/fee_base.mdx new file mode 100644 index 0000000..fe4b347 --- /dev/null +++ b/src/content/docs/br/docs/hooks/functions/ledger/fee_base.mdx @@ -0,0 +1,73 @@ +--- +title: fee_base +description: Fetch the fee base of the current ledger +--- +import { Tabs, TabItem, LinkButton } from '@astrojs/starlight/components'; + +### Concepts + +Hook Fees + +### Behaviour + +* Return the fee base from the current ledger + +### Definition + + + +```c +int64_t fee_base(); +``` + + + +```javascript +function fee_base(): number +``` + + + + + +### Example + + + +```c +int64_t fee = + fee_base(); +``` + + + +```javascript +const fee = fee_base() +``` + + + + + +### Parameters + +This API takes no parameters. + +### Return Code + + + +| Type | Description | +| -------- | ---------------------------------- | +| int64_t | The fee base of the current ledger | + + + + + +| Type | Description | +| ------ | ---------------------------------- | +| number | The fee base of the current ledger | + + + diff --git a/src/content/docs/br/docs/hooks/functions/ledger/ledger_keylet.mdx b/src/content/docs/br/docs/hooks/functions/ledger/ledger_keylet.mdx new file mode 100644 index 0000000..211512d --- /dev/null +++ b/src/content/docs/br/docs/hooks/functions/ledger/ledger_keylet.mdx @@ -0,0 +1,124 @@ +--- +title: ledger_keylet +description: Search for a keylet within a specified range on the current ledger +--- +import { Tabs, TabItem } from '@astrojs/starlight/components'; + +### Behaviour + + + +* Read a 34 byte Keylet from the `lread_ptr` +* Read a 32 byte Keylet from the `hread_ptr` +* Search the ledger for the first (lowest) Keylet of this type in this range. +* If any matching Keylet is found, write it to `write_ptr`. + + + +* This function searches the ledger for the first (`lowest`) Keylet of this type in the given range. +* Returns the number of bytes written (34 bytes) on success, or an error code if an error occurs. + + + + + +### Definition + +C + + + +```c +int64_t ledger_keylet ( + uint32_t write_ptr, + uint32_t write_len, + uint32_t lread_ptr, + uint32_t lread_len, + uint32_t hread_ptr, + uint32_t hread_len +); +``` + + + + + +```javascript +function ledger_keylet( + low: ByteArray | HexString, + high: ByteArray | HexString + ): ErrorCode | ByteArray +``` + + + + + +### Example + +C + + + +```c +//TODO +``` + + + + + +```javascript +ledger_keylet(low, high) +``` + + + + + +### Parameters + + + +| Name | Type | Description | +| ---------- | --------- | ---------------------------------------------------------------------------------------------------------- | +| write_ptr | uint32_t | Pointer to a buffer to store the output serialised Keylet. . | +| write_len | uint32_t | Length of the output buffer. Must be 34 bytes | +| lread_ptr | uint32_t | Pointer to the 34 byte serialised Keylet that represents the lower boundary of the Keylet range to search. | +| lread_len | uint32_t | Always 34 bytes | +| hread_ptr | uint32_t | Pointer to the 34 byte serialised Keylet that represents the upper boundary of the Keylet range to search. | +| hread_len | uint32_t | Always 34 bytes | + + + + + + + +| Name | Type | Description | +| ---- | ---------------------- | ---------------------------------------------------------------------------------------------------------- | +| low | ByteArray \| HexString | Pointer to the 34-byte serialized Keylet that represents the lower boundary of the Keylet range to search. | +| high | ByteArray \| HexString | Pointer to the 34-byte serialized Keylet that represents the upper boundary of the Keylet range to search. | + + + + + +### Return Code + + + +| Type | Description | +| -------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| int64_t |

The number of bytes written (34 bytes) on success.

If negative, an error:
OUT_OF_BOUNDS
- pointers/lengths specified outside of hook memory.

TOO_SMALL / TOO_BIG
- write_len, lread_len or hread_len was not 34 bytes

INVALID_ARGUMENT
- One or more of the provided Keylets was not a valid serialised Keylet

DOES_NOT_MATCH
- The two provided Keylets were not of the same Keylet Type.

DOESNT_EXIST
- No matching Keylet was found in the specified range.

| + + + + + +| Type | Description | +| ---------------------- | ----------------------------------------------------------------------------------------------- | +| ErrorCode \| ByteArray | Returns the number of bytes written (34 bytes) on success, or an error code if an error occurs. | + + + diff --git a/src/content/docs/br/docs/hooks/functions/ledger/ledger_last_hash.mdx b/src/content/docs/br/docs/hooks/functions/ledger/ledger_last_hash.mdx new file mode 100644 index 0000000..3a23bb9 --- /dev/null +++ b/src/content/docs/br/docs/hooks/functions/ledger/ledger_last_hash.mdx @@ -0,0 +1,98 @@ +--- +title: ledger_last_hash +description: Retreive the 32 byte namespace biased SHA512H of the last closed ledger +--- +import { Tabs, TabItem } from '@astrojs/starlight/components'; + +### Behaviour + + + +* Write the 32 byte Hash to the write_ptr + + + +* Retrieves the hash of the last ledger. + + + +### Definition + + + +```c +int64_t ledger_last_hash ( + uint32_t write_ptr, + uint32_t write_len +); +``` + + + + + +```javascript +function ledger_last_hash(): ErrorCode | ByteArray +``` + + + + + +### Example + + + +```c +uint8_t hash[32]; +int64_t bytes_written = + ledger_last_hash(hash, 32); +``` + + + +```javascript +const hash = ledger_last_hash() +``` + + + + + +### Parameters + + + +| Name | Type | Description | +| ---------- | --------- | ---------------------------------------------------------------------------------------- | +| write_ptr | uint32_t | Pointer to a buffer of a suitable size to store the output. Should be at least 32 bytes. | +| write_len | uint32_t | Length of the output buffer. | + + + + + + + + + + + +### Return Code + + + +| Type | Description | +| -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ | +| int64_t |

The number of bytes written

If negative, an error:
OUT_OF_BOUNDS
- pointers/lengths specified outside of hook memory.

| + + + + + +| Type | Description | +| ------ | ----------------------------------------------------------------------------------------------- | +| number | Returns an error code if an error occurs, or an array representing the hash of the last ledger. | + + + diff --git a/src/content/docs/br/docs/hooks/functions/ledger/ledger_last_time.mdx b/src/content/docs/br/docs/hooks/functions/ledger/ledger_last_time.mdx new file mode 100644 index 0000000..fbe7a23 --- /dev/null +++ b/src/content/docs/br/docs/hooks/functions/ledger/ledger_last_time.mdx @@ -0,0 +1,79 @@ +--- +title: ledger_last_time +description: Fetch the last closed ledger's timestamp +--- +import { Aside, Tabs, TabItem } from '@astrojs/starlight/components'; + +### Behaviour + +* Return the Xahau Timestamp from the last closed ledger. + + + +### Definition + + + +```c +int64_t ledger_last_time(); +``` + + + + + +```javascript +function ledger_last_time(): ErrorCode | number +``` + + + +### Example + + + +```c +int64_t ts = + ledger_last_time(); +``` + + + + + +```javascript +const ts = ledger_last_time() +``` + + + + + +### Parameters + +This API takes no parameters. + +### Return Code + + + +| Type | Description | +| -------- | -------------------------------------------- | +| int64_t | The XRPL timestamp of the last closed ledger | + + + + + + + +| Type | Description | +| ------ | ---------------------------------------------------------------------------------------------------- | +| number | Returns an error code if an error occurs, or a number representing the timestamp of the last ledger. | + + + diff --git a/src/content/docs/br/docs/hooks/functions/ledger/ledger_nonce.mdx b/src/content/docs/br/docs/hooks/functions/ledger/ledger_nonce.mdx new file mode 100644 index 0000000..8553a51 --- /dev/null +++ b/src/content/docs/br/docs/hooks/functions/ledger/ledger_nonce.mdx @@ -0,0 +1,104 @@ +--- +title: ledger_nonce +description: Generate a 32 byte nonce for use in an emitted transaction +--- +import { Tabs, TabItem } from '@astrojs/starlight/components'; + +### Behaviour + + + +* Write a 32 byte random value to the write_ptr + + + +* Retrieves the nonce of the current ledger. + + + + + +### Definition + +C + + + +```c +int64_t ledger_nonce ( + uint32_t write_ptr, + uint32_t write_len +); +``` + + + + + +```javascript +function ledger_nonce(): ErrorCode | ByteArray +``` + + + +### Example + + + +```c +uint8_t n[32]; +int64_t bytes_written = + ledger_nonce(n, 32); +``` + + + + + +```javascript +const nonce = ledger_nonce() +``` + + + + + +### Parameters + + + +| Name | Type | Description | +| ---------- | --------- | ---------------------------------------------------------------------------------------- | +| write_ptr | uint32_t | Pointer to a buffer of a suitable size to store the output. Should be at least 32 bytes. | +| write_len | uint32_t | Length of the output buffer. | + + + + + + + + + + + +### Return Code + + + + + +| Type | Description | +| ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------- | +| ErrorCode \| ByteArray | Returns an error code if an error occurs, or an array representing the nonce of the current ledger. specified outside of hook memory. | + + + + + +| Type | Description | +| -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ | +| int64_t |

The number of bytes written

If negative, an error:
OUT_OF_BOUNDS
- pointers/lengths specified outside of hook memory.

| + + + diff --git a/src/content/docs/br/docs/hooks/functions/ledger/ledger_seq.mdx b/src/content/docs/br/docs/hooks/functions/ledger/ledger_seq.mdx new file mode 100644 index 0000000..f1c6687 --- /dev/null +++ b/src/content/docs/br/docs/hooks/functions/ledger/ledger_seq.mdx @@ -0,0 +1,73 @@ +--- +title: ledger_seq +description: Fetch the current ledger sequence number +--- +import { Tabs, TabItem } from '@astrojs/starlight/components'; + +### Behaviour + +* Return the sequence number from the current ledger + +### Definition + +C + + + +```c +int64_t ledger_seq(); +``` + + + +```javascript +function ledger_seq(): ErrorCode | number +``` + + + + + +### Example + + + +```c +int64_t seq = + ledger_seq(); +``` + + + + + +```javascript +const seq = ledger_seq() +``` + + + + + +### Parameters + +This API takes no parameters. + +### Return Code + + + +| Type | Description | +| -------- | ----------------------------------------- | +| int64_t | The sequence number of the current ledger | + + + + + +| Type | Description | +| ------ | ----------------------------------------- | +| number | The sequence number of the current ledger | + + + diff --git a/src/content/docs/br/docs/hooks/functions/originating-transaction/meta_slot.mdx b/src/content/docs/br/docs/hooks/functions/originating-transaction/meta_slot.mdx new file mode 100644 index 0000000..006e30f --- /dev/null +++ b/src/content/docs/br/docs/hooks/functions/originating-transaction/meta_slot.mdx @@ -0,0 +1,83 @@ +--- +title: meta_slot +description: Load the metadata of the originating transaction into a slot +--- +import { Tabs, TabItem } from '@astrojs/starlight/components'; + +### Behaviour + +* If the Hook is being [Weakly Executed](/docs/hooks/concepts/weak-and-strong) then emplace the metadata of the originating transaction into the slot specified or into a new slot if no slot is specified + +### Definition + + + +```c +int64_t meta_slot ( + uint32_t slot_no +); +``` + + + +```javascript +function meta_slot(slotno: number): ErrorCode | number +``` + + + + + +### Example + + + +```c +int64_t meta_slot_no = + meta_slot(0); +``` + + + +```javascript +const meta_slot_no = meta_slot(0) +``` + + + + + +### Parameters + + + +| Name | Type | Description | +| -------- | --------- | ----------------------------------------------------------------------------- | +| slot_no | uint32_t | The slot number to emplace into, or 0 if you wish to pick the next available. | + + + +| Name | Type | Description | +| ------ | ------ | ----------------------------------------- | +| slotno | number | The slot number to retrieve metadata for. | + + + + + +### Return Code + + + +| Type | Description | +| -------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| int64_t |

The slot the otxn was placed in

INVALID_ARGUMENT
- specified slot number exceeds the largest possible slot number

NO_FREE_SLOTS
- the request could not granted because no free slot was avaialble to place the originating transaction into.

PREREQUISITE_NOT_MET
- The hook is being Strongly Executed and therefore no transactional metadata is available.

| + + + +| Type | Description | +| ------------------- | --------------------------------------------- | +| ErrorCode \| number | Returns an error code or the slot's metadata. | + + + diff --git a/src/content/docs/br/docs/hooks/functions/originating-transaction/otxn_burden.mdx b/src/content/docs/br/docs/hooks/functions/originating-transaction/otxn_burden.mdx new file mode 100644 index 0000000..fdde6db --- /dev/null +++ b/src/content/docs/br/docs/hooks/functions/originating-transaction/otxn_burden.mdx @@ -0,0 +1,78 @@ +--- +title: otxn_burden +description: Get the burden of the originating transaction +--- +import { Tabs, TabItem } from '@astrojs/starlight/components'; + +### Behaviour + + + +* Return the burden of the originating transaction or `1` if no burden field is present. + + + +* Retrieve the burden of the originating transaction. +* Returns the burden as a number, or an ErrorCode if the retrieval fails. + + + +### Definition + + + +```c +int64_t otxn_burden ( + void +); +``` + + + +```javascript +function otxn_burden(): ErrorCode | number +``` + + + + + +### Example + + + +```c +int64_t burden = + otxn_burden(); +``` + + + +```javascript +const burden = otxn_burden() +``` + + + + + +### Parameters + +None + +### Return Code + + + +| Type | Description | +| -------- | ---------------------------------------------------------------------------------------------------------- | +| int64_t | The burden of the originating transaction, or `1` if no burden was present on the originating transaction. | + + + +| Type | Description | +| ------------------- | ----------------------------------------------------------------------- | +| number or ErrorCode | Returns the burden as a number, or an ErrorCode if the retrieval fails. | + + + diff --git a/src/content/docs/br/docs/hooks/functions/originating-transaction/otxn_field.mdx b/src/content/docs/br/docs/hooks/functions/originating-transaction/otxn_field.mdx new file mode 100644 index 0000000..83829fb --- /dev/null +++ b/src/content/docs/br/docs/hooks/functions/originating-transaction/otxn_field.mdx @@ -0,0 +1,103 @@ +--- +title: otxn_field +description: Serialize and output a field from the originating transaction +--- +import { Tabs, TabItem, Aside } from '@astrojs/starlight/components'; + +### Behaviour + + + +* Find the specified `sf` field in the originating transaction +* Write the serialized version of the field to the output buffer + + + +* Retrieve the value of a specific field in the originating transaction. +* Returns the value of the specified field as an array of numbers, or an ErrorCode if the lookup fails. + + + +### Definition + + + +```c +int64_t otxn_field ( + uint32_t write_ptr, + uint32_t write_len, + uint32_t field_id +); +``` + + + +```javascript +function otxn_field(field_id: number): ErrorCode | ByteArray +``` + + + + + +### Example + + + +```c +int64_t account_field_len = + otxn_field(account_field, 20, sfAccount); +``` + + + + + +```javascript +const account_field = otxn_field(sfAccount) +``` + + + + + +### Parameters + + + +| Name | Type | Description | +| ---------- | --------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| write_ptr | uint32_t | Pointer to a buffer of a suitable size to store the output. | +| write_len | uint32_t | Length of the output buffer. | +| field_id | uint32_t |

The sf code of the field you are searching for.

To compute this manually take the serialized type and shift it into the 16 highest bits of uint32_t, then take the field and place it in the 16 lowest bits.

For example:
sfEmitNonce has type 5 and field 11 thus its value is 0x050BU

| + + + + + +| Name | Type | Description | +| --------- | ------ | --------------------------------------------------------------------------------------------------- | +| field_id | number |

Returns the value of the specified field as an array of numbers, if the lookup fails.

| + + + +### Return Code + + + +| Type | Description | +| -------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| int64_t |

The number of bytes written

If negative, an error:
OUT_OF_BOUNDS
- pointers/lengths specified outside of hook memory.

TOO_SMALL
- output buffer was not large enough to hold the serialized field

INVALID_FIELD
- the sf field_id was invalid

DOESNT_EXIST
- the field was not found in the originating transaction

| + + + +| Type | Description | +| ---------------------- | ------------------------------------------------------------------------------------------------------------------- | +| ByteArray or ErrorCode |

Returns the value of the specified field as an array of numbers, or an ErrorCode if the lookup fails.

| + + + diff --git a/src/content/docs/br/docs/hooks/functions/originating-transaction/otxn_generation.mdx b/src/content/docs/br/docs/hooks/functions/originating-transaction/otxn_generation.mdx new file mode 100644 index 0000000..e40bb22 --- /dev/null +++ b/src/content/docs/br/docs/hooks/functions/originating-transaction/otxn_generation.mdx @@ -0,0 +1,78 @@ +--- +title: otxn_generation +description: Get the generation of the originating transaction +--- +import { Tabs, TabItem } from '@astrojs/starlight/components'; + +### Behaviour + + + +* Return the generation of the originating transaction or `1` if no generation field is present. + + + +* Retrieve the generation number of the originating transaction. +* Returns the generation number as a number. + + + +### Definition + + + +```c +int64_t otxn_generation ( + void +); +``` + + + +```javascript +function otxn_generation(): number +``` + + + + + +### Example + + + +```c +int64_t generation = + otxn_generation(); +``` + + + +```javascript +const generation = otxn_generation() +``` + + + + + +### Parameters + +None + +### Return Code + + + +| Type | Description | +| ------ | ------------------------------------------ | +| number | Returns the generation number as a number. | + + + +| Type | Description | +| -------- | ------------------------------------------------------------------------------------------------------------------ | +| int64_t | The generation of the originating transaction, or `1` if no generation was present on the originating transaction. | + + + diff --git a/src/content/docs/br/docs/hooks/functions/originating-transaction/otxn_id.mdx b/src/content/docs/br/docs/hooks/functions/originating-transaction/otxn_id.mdx new file mode 100644 index 0000000..4fbc2cd --- /dev/null +++ b/src/content/docs/br/docs/hooks/functions/originating-transaction/otxn_id.mdx @@ -0,0 +1,98 @@ +--- +title: otxn_id +description: Output the canonical hash of the originating transaction +--- +import { Tabs, TabItem } from '@astrojs/starlight/components'; + +### Behaviour + + + +* Write the canonical hash of the originating transaction to the output buffer. +* If flags = 1 and the transaction is an EMIT_FAILURE transaction then write the canonical hash of the originating transaction that caused the emission. + + + +* Output the canonical hash of the originating transaction. +* Returns the transaction hash as an array of numbers, or an ErrorCode if the retrieval fails. + + + +### Definition + + + +```c +int64_t otxn_id ( + uint32_t write_ptr, + uint32_t write_len, + uint32_t flags +); +``` + + + +```javascript +function otxn_id(flag: number): ErrorCode | ByteArray +``` + + + + + +### Example + + + +```c +uint8_t txn_id[32]; +int64_t bytes_written = + otxn_id(txn_id, 32, 0); +``` + + + +```javascript +const tx_id = otxn_id(0) +``` + + + + + +### Parameters + + + +| Name | Type | Description | +| ---------- | --------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| write_ptr | uint32_t | Pointer to a buffer of to store the hash. | +| write_len | uint32_t | Length of the output buffer. Should be at least 32 bytes. | +| flags | uint32_t |

If 0:
Write the canonical hash of the originating transaction.

If 1 AND the originating transaction is an EMIT_FAILURE:
Write the canonical hash of the emitting transaction.

| + + + +| Name | Type | Description | +| ----- | ------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| flags | number |

If 0:
Write the canonical hash of the originating transaction.

If 1 AND the originating transaction is an EMIT_FAILURE:
Write the canonical hash of the emitting transaction.

| + + + + + +### Return Code + + + +| Type | Description | +| -------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| int64_t |

The number of bytes written

If negative, an error:
OUT_OF_BOUNDS
- pointers/lengths specified outside of hook memory.

TOO_SMALL
- output buffer was not large enough to hold the serialized object

| + + + +| Type | Description | +| ---------------------- | -------------------------------------------------------------------------------------------- | +| ErrorCode \| ByteArray | Returns the transaction hash as an array of numbers, or an ErrorCode if the retrieval fails. | + + + diff --git a/src/content/docs/br/docs/hooks/functions/originating-transaction/otxn_json.mdx b/src/content/docs/br/docs/hooks/functions/originating-transaction/otxn_json.mdx new file mode 100644 index 0000000..b37426a --- /dev/null +++ b/src/content/docs/br/docs/hooks/functions/originating-transaction/otxn_json.mdx @@ -0,0 +1,53 @@ +--- +title: otxn_json +description: Output the originating transaction in JSON format. +--- +import { Tabs, TabItem } from '@astrojs/starlight/components'; + +### Behaviour + + + +* Output the originating transaction in JSON format. +* Returns the originating transaction as a JSON object or Transaction, or an ErrorCode if the retrieval fails. + + + +### Definition + + + +```javascript +function otxn_json(): ErrorCode | Record | Transaction +``` + + + + + +### Example + + + +```javascript +const tx_json = otxn_json() +``` + + + + + +### Parameters + +No parameters + +### Return Code + + + +| Type | Description | +| ------------------------------------------------ | ------------------------------------------------------------------------------------------------------------ | +| ErrorCode \| Record\ \| Transaction | Returns the originating transaction as a JSON object or Transaction, or an ErrorCode if the retrieval fails. | + + + diff --git a/src/content/docs/br/docs/hooks/functions/originating-transaction/otxn_param.mdx b/src/content/docs/br/docs/hooks/functions/originating-transaction/otxn_param.mdx new file mode 100644 index 0000000..29b0c93 --- /dev/null +++ b/src/content/docs/br/docs/hooks/functions/originating-transaction/otxn_param.mdx @@ -0,0 +1,102 @@ +--- +title: otxn_param +description: Retrieve the parameter value for a named Invoke transaction parameter +--- +import { Tabs, TabItem } from '@astrojs/starlight/components'; + +### Behaviour + + + +* Look up the value for a named parameter specified in `read_ptr` on the originating transaction. +* Write the parameter's value to `write_ptr` + + + +* Look up the value for a named parameter specified on the originating transaction. +* Returns the value of the specified parameter, or an ErrorCode if the lookup fails. + + + +### Definition + + + +```c +int64_t otxn_param ( + uint32_t write_ptr, + uint32_t write_len, + uint32_t read_ptr, + uint32_t read_len +); +``` + + + +```javascript +function otxn_param(name: ByteArray | HexString): ErrorCode | ByteArray +``` + + + + + +### Example + + + +```c +uint8_t pname[] = {0xCAU, 0xFEU}; +uint8_t pvalue[32]; +int64_t value_len = + otxn_param(pvalue, 32, pname, 2); +``` + + + +```javascript +const pname = [0xCA, 0xFE] +const pvalue = otxn_param(pname) +``` + + + + + +### Parameters + + + +| Name | Type | Description | +| ---------- | --------- | ---------------------------------------------------------------------------------------- | +| write_ptr | uint32_t | Pointer to a buffer of a suitable size to store the output. Should be at least 32 bytes. | +| write_len | uint32_t | Length of the output buffer. | +| read_ptr | uint32_t | Pointer to a buffer containing the parameter's name | +| read_len | uint32_t | Length of the parameter's name | + + + +| Name | Type | Description | +| ---- | ---------------------- | ------------------------------------------------------------------------- | +| name | ByteArray \| HexString | The name of the parameter to look up, specified as a ByteArray or string. | + + + + + +### Return Code + + + +| Type | Description | +| -------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| int64_t |

The number of bytes written

If negative, an error:
OUT_OF_BOUNDS
- pointers/lengths specified outside of hook memory.

DOESNT_EXIST
- The specified paramater doesn't exist or is null

TOO_SMALL
- The parameter name can't be null

TOO_BIG
- The parameter name is greater than 32 bytes

| + + + +| Type | Description | +| ---------------------- | ---------------------------------------------------------------------------------- | +| ErrorCode \| ByteArray | Returns the value of the specified parameter, or an ErrorCode if the lookup fails. | + + + diff --git a/src/content/docs/br/docs/hooks/functions/originating-transaction/otxn_slot.mdx b/src/content/docs/br/docs/hooks/functions/originating-transaction/otxn_slot.mdx new file mode 100644 index 0000000..343c73f --- /dev/null +++ b/src/content/docs/br/docs/hooks/functions/originating-transaction/otxn_slot.mdx @@ -0,0 +1,83 @@ +--- +title: otxn_slot +description: Load the originating transaction into a slot +--- +import { Tabs, TabItem } from '@astrojs/starlight/components'; + +### Behaviour + +* Emplace the originating transaction into the slot specified or into a new slot if no slot is specified + +### Definition + + + +```c +int64_t otxn_slot ( + uint32_t slot_no +); +``` + + + +```javascript +function otxn_slot(slotno: number): ErrorCode | ByteArray +``` + + + + + +### Example + + + +```c +int64_t otxn_slot_no = + otxn_slot(0); +``` + + + +```javascript +const otxn_slot_no = otxn_slot(0) +``` + + + + + +### Parameters + + + +| Name | Type | Description | +| -------- | --------- | ----------------------------------------------------------------------------- | +| slot_no | uint32_t | The slot number to emplace into, or 0 if you wish to pick the next available. | + + + +| Name | Type | Description | +| ------ | ------ | --------------------------- | +| slotno | number | The slot number to look up. | + + + + + +### Return Code + + + +| Type | Description | +| -------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| int64_t |

The slot the otxn was placed in

INVALID_ARGUMENT
- specified slot number exceeds the largest possible slot number

NO_FREE_SLOTS
- the request could not granted because no free slot was avaialble to place the originating transaction into.

| + + + +| Type | Description | +| ---------------------- | -------------------------------------------------------------------------------------------------------------------------------------- | +| ErrorCode \| ByteArray |

Returns the value associated with the specified slot number as an array of numbers, or an ErrorCode if the lookup fails.

| + + + diff --git a/src/content/docs/br/docs/hooks/functions/originating-transaction/otxn_type.mdx b/src/content/docs/br/docs/hooks/functions/originating-transaction/otxn_type.mdx new file mode 100644 index 0000000..c0850cf --- /dev/null +++ b/src/content/docs/br/docs/hooks/functions/originating-transaction/otxn_type.mdx @@ -0,0 +1,110 @@ +--- +title: otxn_type +description: Get the Transaction Type of the originating transaction +--- +import { Tabs, TabItem } from '@astrojs/starlight/components'; + +### Behaviour + +* Return the Transaction Type of the originating transaction + +### Definition + + + +```c +int64_t otxn_type ( + void +); +``` + + + + + +```javascript +function otxn_type(): ErrorCode | number +``` + + + + + +### Example + + + +```c +int64_t tt = + otxn_type(); +``` + + + +```javascript +const tt = txn_type() +``` + + + +### Parameters + +None + +### Return Code + + + +| Type | Description | +| -------- | ----------------------------------------------------------------------------------------------------------------------------------- | +| int64_t | The Transaction Type of the originating transaction. Check the table below for a list of known Transaction Types at time of writing | + + + +| Type | Description | +| ------------------- | --------------------------------------------------------------------------------- | +| ErrorCode \| number | Returns the Transaction Type as a number, or an ErrorCode if the retrieval fails. | + + + + + +### Known Transaction Types + +| Name | Value | +| ------------------------------- | ----- | +| ttPAYMENT | 0 | +| ttESCROW_CREATE | 1 | +| ttESCROW_FINISH | 2 | +| ttACCOUNT_SET | 3 | +| ttESCROW_CANCEL | 4 | +| ttREGULAR_KEY_SET | 5 | +| ttOFFER_CREATE | 7 | +| ttOFFER_CANCEL | 8 | +| ttTICKET_CREATE | 10 | +| ttTICKET_CANCEL | 11 | +| ttSIGNER_LIST_SET | 12 | +| ttPAYCHAN_CREATE | 13 | +| ttPAYCHAN_FUND | 14 | +| ttPAYCHAN_CLAIM | 15 | +| ttCHECK_CREATE | 16 | +| ttCHECK_CASH | 17 | +| ttCHECK_CANCEL | 18 | +| ttDEPOSIT_PREAUTH | 19 | +| ttTRUST_SET | 20 | +| ttACCOUNT_DELETE | 21 | +| ttHOOK_SET | 22 | +| ttURITOKEN_MINT | 45 | +| ttURITOKEN_BURN | 46 | +| ttURITOKEN_BUY | 47 | +| ttURITOKEN_CREATE_SELL_OFFER | 48 | +| ttURITOKEN_CANCEL_SELL_OFFER | 49 | +| ttGENESIS_MINT | 96 | +| ttIMPORT | 97 | +| ttCLAIM_REWARD | 98 | +| ttINVOKE | 99 | +| ttAMENDMENT | 100 | +| ttFEE | 101 | +| ttUNL_MODIFY | 102 | +| ttEMIT_FAILURE | 103 | +| ttUNL_REPORT | 104 | diff --git a/src/content/docs/br/docs/hooks/functions/overview/hook-api-conventions.mdx b/src/content/docs/br/docs/hooks/functions/overview/hook-api-conventions.mdx new file mode 100644 index 0000000..4bab132 --- /dev/null +++ b/src/content/docs/br/docs/hooks/functions/overview/hook-api-conventions.mdx @@ -0,0 +1,69 @@ +--- +title: Hook API Conventions +--- +import { Tabs, TabItem } from '@astrojs/starlight/components'; + +### Naming conventions + +All Hook APIs follow a standard naming convention: + +| | | | | +| --------- | --------------- | ------------ | --------------- | +| namespace | \[ _ noun #1 ] | \[ _ verb ] | \[ _ noun #2 ] | + +This may look confusing at first but is actually quite simple: + +* If the first noun is missing then it is implicitly the same as the namespace +* If the verb is missing then it is implicitly `get` + +Thus: + +* `state()` means: fetch a hook state. +* `state_set()` means: set a hook. +* `state_foreign()` means: fetch a foreign hook state. + +### Memory model + +Each Hook executes as a singular stack frame. All working memory must exist within this stackframe. There is no heap and no dynamic memory. + +When Hooks communicate with `xahaud` they can only pass _integer_ values. Typically these integers are pointers within the Hook's memory. Since the Hook runs within xahaud, these points can then be resolved by xahaud and written to or read from as needed to perform the Hook API function. + +### Allowed functions + +Only two functions are allowed within a Hook: `hook()` and `cbak()`. Read about this [here](/docs/hooks/concepts/compiling-hooks) + +### Parameters + + + +All parameters passed to a Hook API must be one of: `uint32_t, int32_t, uint64_t, int64_t`. Typically these are pointers and lengths of buffers within the Hook's stack frame. Sometimes they are [Integer Encoded Floating Point Numbers (XFL)](/docs/hooks/concepts/floating-point-numbers-xfl) or other data. + +The parameters to a Hook API are always in the following order: + +1. Writing pointer _if any_ +2. Writing length _if any_ +3. Reading pointer _if any_ +4. Reading length _if any_ +5. Specifics / other fields _if any_ + +Some Hook APIs may only write or may only read from memory, and some might not do either and return a value only by return code. + + + +All parameters passed to a Hook API must be one of: `string, number[], bigint(xfl), object(json)`. Typically these are pointers and lengths of buffers within the Hook's stack frame. Sometimes they are [Integer Encoded Floating Point Numbers (XFL)](/docs/hooks/concepts/floating-point-numbers-xfl) or other data. + +The parameters to a Hook API are always in the following order: + +1. Writing variable _if any_ +2. Reading variable _if any_ +3. Specifics / other fields _if any_ + +Some Hook APIs may only write or may only read from memory, and some might not do either and return a value only by return code. + + + + + +### Return codes + +All Hook APIs return a _signed integer_. Read about return codes here: [Return codes](/docs/hooks/functions/overview/return-codes) diff --git a/src/content/docs/br/docs/hooks/functions/overview/return-codes.mdx b/src/content/docs/br/docs/hooks/functions/overview/return-codes.mdx new file mode 100644 index 0000000..c6e6cd8 --- /dev/null +++ b/src/content/docs/br/docs/hooks/functions/overview/return-codes.mdx @@ -0,0 +1,65 @@ +--- +title: Return Codes +--- +### Return code design + +Web assembly allows for exceptions (traps) however this language feature is not used for Hooks. Instead there is only one way to return from any Hook API (you may think of every Hook API as being `noexcept`). + +To provide for efficient error handling: + +1. All Hook API functions return a _signed_ integer. +2. All negative return codes are an error. +3. All return codes `0` or greater are a function specific output, usually but not always the number of bytes read or written. + +### Error codes + +Error codes are global across all Hook APIs and may be found in the table below. + +| Name | Value | Description | +| ---------------------------------- | ------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| SUCCESS | >= 0 | Non-negative return codes refer always to success and usually indicate the number of bytes written or events performed, depending on the specific API. | +| OUT_OF_BOUNDS | -1 | A pointer or buffer length provided as a parameter described memory outside of the Hook's allowed memory region. | +| INTERNAL_ERROR | -2 | Reserved for internal invariant trips, generally unrelated to inputs. These should be reported with an issue. | +| TOO_BIG | -3 | Attempted to set a parameter or value larger than the allowed space. | +| TOO_SMALL | -4 | The API was unable to produce output to the write_ptr because the specified write_len was too small. | +| DOESNT_EXIST | -5 | The requested object or item wasn't found. | +| NO_FREE_SLOTS | -6 | The Hook attempted to allocate an item into a slot, but there were no slots free. To avoid ensure re-use of existing slots. The maximum number of slots is 255. | +| INVALID_ARGUMENT | -7 | One or more of the parameters to the API were invalid according to the individual API's specification. | +| ALREADY_SET | -8 | Some APIs allow for a once-per-execution parameter to be set. A second attempt to set a once-per-execution parameter results in this error. | +| PREREQUISITE_NOT_MET | -9 | An API required the Hook to do something before the API is allowed to be called. Check the API's documentation. | +| FEE_TOO_LARGE | -10 | During fee calculation if an absurdly large fee is calculated this error is returned. | +| EMISSION_FAILURE | -11 | An attempt to `emit()` a TXN was unsccessful for any of a number of reasons. Check the `trace` log of the rippled to which you are submitting the originating TXN. | +| TOO_MANY_NONCES | -12 | A Hook may only use up to 256 calls to `nonce()` per execution. Further calls result in this error code. | +| TOO_MANY_EMITTED_TXN | -13 |

A Hook must declare ahead of time how many TXN it intends to emit().
If it emits fewer than this many, this is allowed.
If it emits more than this many this error is returned.

| +| NOT_IMPLEMENTED | -14 | While Hooks is/was in development an API may return this if some or all of that API is planned but not yet implemented. | +| INVALID_ACCOUNT | -15 | An API which accepts a 20 byte Account ID may return this if, in its opinion, the Account ID was not valid for any reason. | +| GUARD_VIOLATION | -16 | All loops inside a Hook must declare at the top of the loop, as the first non trivial instruction, before any branch instruction, the promised maximum number of iterations of the loop. If this promise is violated the hook terminates immediately with this error code. | +| INVALID_FIELD | -17 | The requested serialized field could not be found in the specified object. | +| PARSE_ERROR | -18 | While parsing serialized content an error was encountered (typically indicating an invalidly serialized object). | +| RC_ROLLBACK | -19 | Used internally to communicate a rollback event. | +| RC_ACCEPT | -20 | Used internally to communicate an accept event. | +| NO_SUCH_KEYLET | -21 | Specified keylet could not be found, or keylet is invalid | +| NOT_AN_ARRAY | -22 | API was asked to assume object under analysis is an STArray but it was not. | +| NOT_AN_OBJECT | -23 | API was asked to assume object under analysis is an STObject but it was not. | +| INVALID_FLOAT | -10024 | A floating point operation resulted in Not-A-Number or API call attempted to specify an XFL floating point number outside of the expressible range of XFL. | +| DIVISION_BY_ZERO | -25 | API call would result in a division by zero, so API ended early. | +| MANITSSA_OVERSIZED | -26 | When attempting to create an XFL the mantissa must be 16 decimal digits. | +| MANTISSA_UNDERSIZED | -27 | When attempting to create an XFL the mantissa must be 16 decimal digits. | +| EXPONENT_OVERSIZED | -28 | When attempting to create an XFL the exponent must not exceed 80. | +| EXPONENT_UNDERSIZED | -29 | When attempting to create an XFL the exponent must not be less than -96. | +| OVERFLOW | -30 | A floating point operation done on an XFL resulted in a value larger than XFL format is able to represent. | +| NOT_IOU_AMOUNT | -31 | An API assumed an STAmount was an IOU when in fact it was XRP. | +| NOT_AN_AMOUNT | -32 | An API assumed an STObject was an STAmount when in fact it was not. | +| CANT_RETURN_NEGATIVE | -33 | An API would have returned a negative integer except that negative integers are reserved for error codes (i.e. what you are reading.) | +| NOT_AUTHORIZED | -34 | Hook attempted to set foreign state but was not authorized to do so (grant was missing or invalid.) | +| PREVIOUS_FAILURE_PREVENTS_RETRY | -35 | Hook previously received a `NOT_AUTHORIZED` return code and is not allowed to retry. | +| TOO_MANY_PARAMS | -36 | Attempted to set a hook parameter for a later hook in the chain, but there are now too many parameters. | +| INVALID_TXN | -37 | Serialized transaction was not a valid transaction (usually because of a missing required field or data corruption / truncation.) | +| RESERVE_INSUFFICIENT | -38 | Setting an additional state object on this account would cause the reserve requirements to exceed the account's balance. | +| COMPLEX_NOT_SUPPORTED | -39 | Hook API would be forced to return a complex number, which it cannot do. | +| DOES_NOT_MATCH | -40 | Two arguments were required to be of the same type but are not. | +| INVALID_KEY | -41 | The provided public key was not valid. | +| NOT_A_STRING | -42 | The buffer did not contain a nul terminated string. | +| MEM_OVERLAP | -43 | The writing pointer points to a buffer that overlaps with the reading pointer. | +| TOO_MANY_STATE_MODIFICATIONS | -44 | More than 5000 modified state entries in the combined hook chains | +| TOO_MANY_NAMESPACES | -45 | More than 256 namespaces on this account | diff --git a/src/content/docs/br/docs/hooks/functions/serialization/sto_emplace.mdx b/src/content/docs/br/docs/hooks/functions/serialization/sto_emplace.mdx new file mode 100644 index 0000000..f28a032 --- /dev/null +++ b/src/content/docs/br/docs/hooks/functions/serialization/sto_emplace.mdx @@ -0,0 +1,142 @@ +--- +title: sto_emplace +description: Emplace a field into an existing STObject at its canonical placement +--- +import { Tabs, TabItem, LinkButton, Aside } from '@astrojs/starlight/components'; + +### Concepts + +Serialized Objects + +### Behaviour + + + +* Parse an STObject `S` (source object) pointed to by `sread_ptr` +* Parse an STObject `F` (to inject/emplace) pointed to by `fread_ptr` +* Write a new STObject to `write_ptr` which places `F` into `S` at the canonical position `field_id` + + + + + +* Ask for the STO object by the param `sto` +* Ask for the bytes representing the field to be added by the param `field_bytes` +* Ask for the ID of the field to be added by the param `field_id` +* Return the updated STO object in binary encoded ledger data format, or an error code if the operation fails. + + + +### Definition + +C + + + +```c +int64_t sto_emplace ( + uint32_t write_ptr, + uint32_t write_len, + uint32_t sread_ptr, + uint32_t sread_len, + uint32_t fread_ptr, + uint32_t fread_len, + uint32_t field_id +); +``` + + + + + +```javascript +function sto_emplace( + sto: ByteArray | HexString, + field_bytes: ByteArray | HexString, + field_id: number + ): ErrorCode | ByteArray +``` + + + + + +### Example + + + +```c +uint8_t tx_out[1024]; + +int64_t tx_len = + sto_emplace(tx_out, sizeof(tx_out), + tx_in, tx_len, + sequence_field, 5, sfSequence); + +if (tx_len <= 0) + rollback("Emplacing failed.", 17, 1); +``` + + + + + +```javascript +const tx_out = sto_emplace(tx_in, sequence_field, sfSequence) +if (typeof tx_out === 'number') + rollback("Emplacing failed.", 1) +``` + + + + + +### Parameters + + + +| Name | Type | Description | +| ---------- | --------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| write_ptr | uint32_t | The buffer to write the modified STObject to | +| write_len | uint32_t | The length of the output buffer | +| sread_ptr | uint32_t | The buffer to read the source STObject from | +| sread_len | uint32_t | The Length of the source object | +| fread_ptr | uint32_t | The buffer to read the field to be emplaced/injected from | +| fread_len | uint32_t | The length of the field to be emplaced/injected | +| field_id | uint32_t | The `sf` code (location) to form the emplacement. If this already exists in the source object then the existing field is overriden. If it doesn't exist it is inserted. | + + + + + + + +| Name | Type | Description | +| ------------ | ---------------------- | ----------------------------------------------------------------------------- | +| sto | ByteArray \| HexString | The STO object (binary encoded ledger data) to which the field will be added. | +| field_bytes | ByteArray \| HexString | The bytes representing the field to be added. | +| field_id | number | The ID of the field to be added. | + + + + + +### Return Code + + + +
TypeDescription
int64_tThe number of bytes written to write_ptr

If negative, an error:
OUT_OF_BOUNDS
- pointers/lengths specified outside of hook memory.

TOO_SMALL
- Output buffer must be at least as large as the source object + the injected field, even if the field is only being overriden.

TOO_BIG
- Field you are attempting to emplace is too large

PARSE_ERROR
- The supplied STObject is malformed or not an STObject.
+ + + + + + + +
TypeDescription
ErrorCode | ByteArrayThe updated STO object in binary encoded ledger data format, or an error code if the operation fails.
+ + + diff --git a/src/content/docs/br/docs/hooks/functions/serialization/sto_erase.mdx b/src/content/docs/br/docs/hooks/functions/serialization/sto_erase.mdx new file mode 100644 index 0000000..48b533e --- /dev/null +++ b/src/content/docs/br/docs/hooks/functions/serialization/sto_erase.mdx @@ -0,0 +1,128 @@ +--- +title: sto_erase +description: Remove a field from an STObject +--- +import { Tabs, TabItem, LinkButton, Aside } from '@astrojs/starlight/components'; + +### Concepts + +Serialized Objects + +### Behaviour + + + +* Parse an STObject pointed to by `read_ptr` +* Write a new STObject to `write_ptr` but without `field_id` if it was present in the original object. + + + +* It will look for the STO object (binary encoded ledger data) from which the field will be removed. +* It will look for the ID of the field to be erased. +* Returns the updated STO object in binary encoded ledger data format, or an error code if the operation fails. + + + +### Definition + + + +```c +int64_t sto_erase ( + uint32_t write_ptr, + uint32_t write_len, + uint32_t read_ptr, + uint32_t read_len, + uint32_t field_id +); +``` + + + + + +```javascript +function sto_erase( + sto: ByteArray | HexString, + field_id: number + ): ErrorCode | ByteArray +``` + + + + + +### Example + + + +```c +int64_t result = + sto_erase(tx_out, sizeof(tx_out), + tx_in, tx_len, sfSigners); + +if (tx_len <= 0) + rollback("Erasing failed.", 15, 1); +``` + + + + + +```javascript +const tx_out = sto_erase(tx_in, sfSigners) + +if (typeof tx_out === 'number') + rollback("Erasing failed.", 1) +``` + + + +### Parameters + + + +| Name | Type | Description | +| ---------- | --------- | -------------------------------------------- | +| write_ptr | uint32_t | The buffer to write the modified STObject to | +| write_len | uint32_t | The length of the output buffer | +| read_ptr | uint32_t | The buffer to read the source STObject from | +| read_len | uint32_t | The Length of the source object | +| field_id | uint32_t | The `sf` code (location) to erase | + + + + + +| Name | Type | Description | +| --------- | ---------------------- | --------------------------------------------------------------------------------- | +| sto | ByteArray \| HexString | The STO object (binary encoded ledger data) from which the field will be removed. | +| field_id | number | The ID of the field to be erased. | + + + + + +### Return Code + + + +| Type | Description | +| -------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| int64_t |

The number of bytes written to write_ptr

If negative, an error:
OUT_OF_BOUNDS
- pointers/lengths specified outside of hook memory.

TOO_SMALL
- Output buffer must be at least as large as the source object.

TOO_BIG
- Field you are attempting to erase from is too large

PARSE_ERROR
- The supplied STObject is malformed or not an STObject.

DOESNT_EXIST
- The specified field_id isn't present in the STObject.

| + + + + + +| Type | Description | +| ---------------------- | ----------------------------------------------------------------------------------------------------- | +| ErrorCode \| ByteArray | The updated STO object in binary encoded ledger data format, or an error code if the operation fails. | + + + diff --git a/src/content/docs/br/docs/hooks/functions/serialization/sto_from_json.mdx b/src/content/docs/br/docs/hooks/functions/serialization/sto_from_json.mdx new file mode 100644 index 0000000..568bb7c --- /dev/null +++ b/src/content/docs/br/docs/hooks/functions/serialization/sto_from_json.mdx @@ -0,0 +1,73 @@ +--- +title: sto_from_json +description: Format JSON as an STO object (binary encoded ledger data). +--- +import { Tabs, TabItem, LinkButton } from '@astrojs/starlight/components'; + +### Concepts + +Serialized Objects + +### Behaviour + + + +* Takes a JSON object and converts it into a binary encoded ledger data format. +* Returns STO Object in binary encoded ledger data format, or an error code if the conversion fails. + + + + + +### Definition + + + +```javascript +function sto_from_json( + jsonobj: Record | Transaction + ): ErrorCode | ByteArray +``` + + + + + +### Example + + + +```javascript +const stoBlob = sto_from_json(stoJson) +``` + + + + + +### Parameters + + + + + +| Name | Type | Description | +| ------- | ----------------------------------- | ----------------------------------------------- | +| jsonobj | Record\ \| Transaction | JSON object to be converted into an STO object. | + + + + + +### Return Code + + + + + +| Type | Description | +| ---------------------- | ------------------------------------------------------------------------------------------ | +| ErrorCode \| ByteArray | STO Object in binary encoded ledger data format, or an error code if the conversion fails. | + + + diff --git a/src/content/docs/br/docs/hooks/functions/serialization/sto_subarray.mdx b/src/content/docs/br/docs/hooks/functions/serialization/sto_subarray.mdx new file mode 100644 index 0000000..49eece1 --- /dev/null +++ b/src/content/docs/br/docs/hooks/functions/serialization/sto_subarray.mdx @@ -0,0 +1,157 @@ +--- +title: sto_subarray +description: >- + Index into a xahaud serialized array and return the location and length of an + index +--- +import { Tabs, TabItem, LinkButton, Aside } from '@astrojs/starlight/components'; + +### Concepts + +Serialized Objects + +### Behaviour + + + +* Parse a STArray pointed to by `read_ptr` +* Find the array index specified by `array_id` +* Return the byte offset and length of the serialized field within the STObject, if it is found + + + + + +* Ask for the STO object (binary encoded ledger data) from which to extract the subarray. +* Find the array index specified by `array_id` +* Return a subarray from an STO object. + + + +### Definition + + + +```c +int64_t sto_subarray ( + uint32_t read_ptr, + uint32_t read_len, + uint32_t array_id +); +``` + + + + + +```javascript +function sto_subarray( + sto: ByteArray | HexString, + array_id: number + ): bigint | number +``` + + + + + +### Example + + + +```c +#define SUB_OFFSET(x) ((int32_t)(x >> 32)) +#define SUB_LENGTH(x) ((int32_t)(x & 0xFFFFFFFFULL)) + + int64_t memo_lookup = + sto_subarray(memos, memos_len, 0); + +if (memo_lookup < 0) +{ + // sfMemo was not found in the STObject pointed at by memo_ptr +} +else +{ + // 0th index of the STArray was found and its location is as follows: + uint8_t* memo_ptr = SUB_OFFSET(memo_lookup) + memos; + uint32_t memo_len = SUB_LENGTH(memo_lookup); +} +``` + + + + + +```javascript +const SUB_OFFSET = (x) => Number(x >> 32n) +const SUB_LENGTH = (x) => Number(x & 0xFFFFFFFFn) + +const memo_lookup = sto_subarray(memos, 0) + +if (typeof memo_lookup === 'number') +{ + // sfMemo was not found in the STObject pointed at +} +else +{ + // 0th index of the STArray was found and its location is as follows: + const memo_start = SUB_OFFSET(memo_lookup) + const memo_len = SUB_LENGTH(memo_lookup) + const memo = memos.slice(memo_start, memo_len) +} +``` + + + +### Parameters + + + +| Name | Type | Description | +| --------- | --------- | ------------------------------------------------------------------------- | +| read_ptr | uint32_t | Pointer to the buffer containing the STArray | +| read_len | uint32_t | Length of STArray | +| array_id | uint32_t | The index of the entry within the STArray you are seeking. Starts from 0. | + + + + + + + +| Name | Type | Description | +| --------- | ---------------------- | ------------------------------------------------------------------------------- | +| sto | ByteArray \| HexString | The STO object (binary encoded ledger data) from which to extract the subarray. | +| array_id | number | The ID of the array to be extracted. | + + + + + +### Return Code + + + +| Type | Description | +| -------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| int64_t |

The location of the field within the specified buffer:
- The high 32 bits are the offset location.
- The low 32 bits are the length.

If negative, an error:
OUT_OF_BOUNDS
- pointers/lengths specified outside of hook memory.

TOO_SMALL
- Input buffer isn't large enough to possibly contain a valid STArray.

DOESNT_EXIST
- The searched for index isn't present in the supplied STArray.

PARSE_ERROR
- The supplied STArray is malformed or not an STArray.

| + + + + + + + +| Type | Description | +| ------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| bigint / ErrorCode |

The location of the field within the specified buffer:
- The high 32 bits are the offset location.
- The low 32 bits are the length.

or an error code if the extraction fails.

| + + + diff --git a/src/content/docs/br/docs/hooks/functions/serialization/sto_subfield.mdx b/src/content/docs/br/docs/hooks/functions/serialization/sto_subfield.mdx new file mode 100644 index 0000000..32b3742 --- /dev/null +++ b/src/content/docs/br/docs/hooks/functions/serialization/sto_subfield.mdx @@ -0,0 +1,158 @@ +--- +title: sto_subfield +description: >- + Index into a xahaud serialized object and return the location and length of a + subfield +--- +import { Tabs, TabItem, LinkButton, Aside } from '@astrojs/starlight/components'; + +### Concepts + +Serialized Objects + +### Behaviour + + + +* Parse a STObject pointed to by `read_ptr` +* Find the field specified by `field_id` +* If the field is found, and: +* + 1. It is an array, then return the start and length of the array including the leadin/leadout bytes, or +* + 2. It is **not** an array, then return the start and length of the PAYLOAD of the field (excluding the leadin bytes). + + + + + +* Parse a STObject into `sto` variable +* Find the field specified by `field_id` + + + + + +### Definition + + + +```c +int64_t sto_subfield ( + uint32_t read_ptr, + uint32_t read_len, + uint32_t field_id +); +``` + + + + + +```javascript +function sto_subfield( + sto: ByteArray | HexString, + field_id: number + ): ErrorCode | bigint +``` + + + + + +### Example + + + +```c +#define SUB_OFFSET(x) ((int32_t)(x >> 32)) +#define SUB_LENGTH(x) ((int32_t)(x & 0xFFFFFFFFULL)) +int64_t memos_lookup = + sto_subfield(txn_ptr, txn_len, sfMemos); +if (memos_lookup < 0) +{ + // sfMemos was not found in the STObject pointed at by memo_ptr +} +else +{ + // sfMemos was found and its location is as follows: + uint8_t* memos_ptr = SUB_OFFSET(memos_lookup) + memos_ptr; + int64_t memos_len = SUB_LENGTH(memos_lookup); +} +``` + + + + + +```javascript +const SUB_OFFSET = (x) => Number(x >> 32n) +const SUB_LENGTH = (x) => Number(x & 0xFFFFFFFFn) +const memos_lookup = sto_subfield(txn, sfMemos); +if (typeof memos_lookup === 'number') +{ + // sfMemos was not found in the STObject pointed at by memo_ptr +} +else +{ + // sfMemos was found and its location is as follows: + const memo_start = SUB_OFFSET(memos_lookup) + const memo_len = SUB_LENGTH(memos_lookup) + const memo = txn.slice(memo_start, memo_len) +} +``` + + + + + +### Parameters + + + +| Name | Type | Description | +| --------- | --------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| read_ptr | uint32_t | Pointer to the buffer containing the STObject | +| read_len | uint32_t | Length of STObject | +| field_id | uint32_t |

The sf code of the field you are searching for.

To compute this manually take the serialized type and shift it into the 16 highest bits of uint32_t, then take the field and place it in the 16 lowest bits.

For example:
sfEmitNonce has type 5 and field 11 thus its value is 0x050BU

| + + + + + + + +| Name | Type | Description | +| --------- | ---------------------- | ------------------------------------------------------------------------------- | +| sto | ByteArray or HexString | The STO object (binary encoded ledger data) from which to extract the subfield. | +| field_id | number | The ID of the field to be extracted. | + + + + + +### Return Code + + + +| Type | Description | +| -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| int64_t |

The location of the field within the specified buffer:
- The high 32 bits are the offset location.
- The low 32 bits are the length.

If negative, an error:
OUT_OF_BOUNDS
- pointers/lengths specified outside of hook memory.

TOO_SMALL
- Input buffer isn't large enough to possibly contain a valid STObject.

DOESNT_EXIST
- The searched for field isn't present in the supplied STObject.

PARSE_ERROR
- The supplied STObject is malformed or not an STObject.

| + + + + + + + +| Type | Description | +| ------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| bigint / ErrorCode |

The location of the field within the specified buffer:
- The high 32 bits are the offset location.
- The low 32 bits are the length.

or an error code if the extraction fails.

| + + + diff --git a/src/content/docs/br/docs/hooks/functions/serialization/sto_to_json.mdx b/src/content/docs/br/docs/hooks/functions/serialization/sto_to_json.mdx new file mode 100644 index 0000000..6c49dfc --- /dev/null +++ b/src/content/docs/br/docs/hooks/functions/serialization/sto_to_json.mdx @@ -0,0 +1,75 @@ +--- +title: sto_to_json +description: Format an STO object (binary encoded ledger data) as JSON format. +--- +import { Tabs, TabItem, LinkButton } from '@astrojs/starlight/components'; + +### Concepts + +Serialized Objects + +### Behaviour + + + +* Format an STO object (binary encoded ledger data) as JSON format. + + This function takes a serialized transaction `blob` and converts it into a human-readable JSON format. +* Returns Decoded JSON representation of the STO object, or an error code if the conversion fails. + + + + + +### Definition + + + +```javascript +function sto_to_json( + blob: ByteArray | HexString + ): ErrorCode | Record | Transaction +``` + + + + + +### Example + + + +```javascript +const jsonSto = sto_to_json(stoBlob) +``` + + + + + +### Parameters + + + + + +| Name | Type | Description | +| ---- | ---------------------- | ------------------------------------------------------- | +| blob | ByteArray \| HexString | The blob (e.g. serialized transaction) to be converted. | + + + + + +### Return Code + + + + + +| Type | Description | +| ------------------------------------------------ | ---------------------------------------------------------------------------------------- | +| ErrorCode \| Record\ \| Transaction | Decoded JSON representation of the STO object, or an error code if the conversion fails. | + + + diff --git a/src/content/docs/br/docs/hooks/functions/serialization/sto_validate.mdx b/src/content/docs/br/docs/hooks/functions/serialization/sto_validate.mdx new file mode 100644 index 0000000..d8042ac --- /dev/null +++ b/src/content/docs/br/docs/hooks/functions/serialization/sto_validate.mdx @@ -0,0 +1,117 @@ +--- +title: sto_validate +description: Validate an STObject +--- +import { Tabs, TabItem, LinkButton } from '@astrojs/starlight/components'; + +### Concepts + +Serialized Objects + +### Behaviour + + + +* Parse an STObject pointed to by `read_ptr` +* Return 1 if the serialization is valid, 0 otherwise. + + + +* The `blob` (e.g. serialized transaction) is provided to be validated. +* Returns number 1 if the STObject is valid, 0 if it isn't, or an error code if validation fails. + + + + + +### Definition + + + +```c +int64_t sto_validate ( + uint32_t read_ptr, + uint32_t read_len +); +``` + + + + + +```javascript +function sto_validate(blob: ByteArray | HexString): ErrorCode | number +``` + + + + + +### Example + + + +```c +int64_t result = + sto_validate(tx_out, sizeof(tx_out)); + +if (tx_len <= 0) + rollback("Invalid STO.", 12, 1); +``` + + + + + +```javascript +const result = sto_validate(tx_out) + +if (result <= 0) + rollback("Invalid STO.", 1) +``` + + + + + +### Parameters + + + +| Name | Type | Description | +| --------- | --------- | ------------------------------------------- | +| read_ptr | uint32_t | The buffer to read the source STObject from | +| read_len | uint32_t | The Length of the source object | + + + + + + + +| Name | Type | Description | +| ---- | ---------------------- | ------------------------------------------------------- | +| blob | ByteArray \| HexString | The blob (e.g. serialized transaction) to be validated. | + + + + + +### Return Code + + + +| Type | Description | +| -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| int64_t |

1 if the STObject pointed to by read_ptr is a valid STObject.
0 if it isn't.

If negative, an error:
OUT_OF_BOUNDS
- pointers/lengths specified outside of hook memory.

| + + + + + +| Type | Description | +| ------------------- | ----------------------------------------------------------------------------------------------- | +| ErrorCode \| number | Returns number 1 if the STObject is valid, 0 if it isn't, or an error code if validation fails. | + + + diff --git a/src/content/docs/br/docs/hooks/functions/slot/slot.mdx b/src/content/docs/br/docs/hooks/functions/slot/slot.mdx new file mode 100644 index 0000000..2915ceb --- /dev/null +++ b/src/content/docs/br/docs/hooks/functions/slot/slot.mdx @@ -0,0 +1,104 @@ +--- +title: slot +description: Serialize and output a slotted object +--- +import { Tabs, TabItem, Aside } from '@astrojs/starlight/components'; + +### Behaviour + + + +* Serialize the object currently occupying the specified slot +* Write the serialized version of the object to the output buffer + + + + + +* Retrieves the JSON Retrieves the data associated with the specified slot. of the specified slot. +* Returns an error code or the slot's data. + + + +### Definition + + + +```c +int64_t slot ( + uint32_t write_ptr, + uint32_t write_len, + uint32_t slot_no +); +``` + + + + + +```javascript +function slot(slotno: number): ErrorCode | ByteArray +``` + + + + + +### Example + + + +```c +uint8_t txn[512]; +int64_t bytes_written = + slot(txn, 512, 1); // assumes a transaction is slotted into slot=1 +``` + + + +```javascript +const txn = slot(1) // assumes a transaction is slotted into slot=1 +``` + + + + + +### Parameters + + + +| Name | Type | Description | +| ---------- | --------- | ----------------------------------------------------------- | +| write_ptr | uint32_t | Pointer to a buffer of a suitable size to store the output. | +| write_len | uint32_t | Length of the output buffer. | +| slot_no | uint32_t | The slot number | + + + +| Name | Type | Description | +| ------ | ------ | --------------- | +| slotno | number | The slot number | + + + + + +### Return Code + + + +| Type | Description | +| -------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| int64_t |

The number of bytes written

If negative, an error:
OUT_OF_BOUNDS
- pointers/lengths specified outside of hook memory.

TOO_SMALL
- output buffer was not large enough to hold the serialized object

| + + + +| Type | Description | +| ---------------------- | ----------------------------------------- | +| ErrorCode \| ByteArray | Returns an error code or the slot's data. | + + + diff --git a/src/content/docs/br/docs/hooks/functions/slot/slot_clear.mdx b/src/content/docs/br/docs/hooks/functions/slot/slot_clear.mdx new file mode 100644 index 0000000..c104199 --- /dev/null +++ b/src/content/docs/br/docs/hooks/functions/slot/slot_clear.mdx @@ -0,0 +1,82 @@ +--- +title: slot_clear +description: Free up a currently occupied slot +--- +import { Tabs, TabItem } from '@astrojs/starlight/components'; + +### Behaviour + +* Free the specified slot, releasing any object that was slotted there + +### Definition + + + +```c +int64_t slot_clear ( + uint32_t slot_no +); +``` + + + +```javascript +function slot_clear(slotno: number): ErrorCode | number +``` + + + + + +### Example + + + +```c +slot_clear(1); // assumes a transaction is slotted into slot=1 +``` + + + +```javascript +slot_clear(1) // assumes a transaction is slotted into slot=1 +``` + + + + + +### Parameters + + + +| Name | Type | Description | +| -------- | --------- | --------------- | +| slot_no | uint32_t | The slot number | + + + +| Name | Type | Description | +| ------ | ------ | --------------- | +| slotno | number | The slot number | + + + + + +### Return Code + + + +| Type | Description | +| -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| int64_t |

1 or an error

If negative, an error:
DOESNT_EXIST
- the specified slot does not contain any object or it is an invalid slot

| + + + +| Type | Description | +| ------------------- | ----------------------------------------------------------- | +| ErrorCode \| number | Returns an error code or the result of the clear operation. | + + + diff --git a/src/content/docs/br/docs/hooks/functions/slot/slot_count.mdx b/src/content/docs/br/docs/hooks/functions/slot/slot_count.mdx new file mode 100644 index 0000000..3568f6a --- /dev/null +++ b/src/content/docs/br/docs/hooks/functions/slot/slot_count.mdx @@ -0,0 +1,83 @@ +--- +title: slot_count +description: Count the elements of an array object in a slot +--- +import { Tabs, TabItem } from '@astrojs/starlight/components'; + +### Behaviour + +* Count the elements of an array in the specified slot +* Return the count + +### Definition + + + +```c +int64_t slot_count ( + uint32_t slot_no +); +``` + + + + + +```javascript +function slot_count(slotno: number): ErrorCode | number +``` + + + + + +### Example + + + +```c +slot_count(1); // assumes an array is slotted into slot=1 +``` + + + +```javascript +slot_count(1) // assumes an array is slotted into slot=1 +``` + + + + + +### Parameters + + + +| Name | Type | Description | +| -------- | --------- | --------------- | +| slot_no | uint32_t | The slot number | + + + +| Name | Type | Description | +| ------ | ------ | --------------- | +| slotno | number | The slot number | + + + +### Return Code + + + +| Type | Description | +| -------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| int64_t |

The number of elements inside the slotted array

If negative, an error:
DOESNT_EXIST
- the specified slot does not contain any object or it is an invalid slot

NOT_AN_ARRAY
- the specified slot does not contain an array object

| + + + +| Type | Description | +| ------------------- | ---------------------------------------------- | +| ErrorCode or number | Returns an error code or the count of entries. | + + + diff --git a/src/content/docs/br/docs/hooks/functions/slot/slot_float.mdx b/src/content/docs/br/docs/hooks/functions/slot/slot_float.mdx new file mode 100644 index 0000000..ee4eec5 --- /dev/null +++ b/src/content/docs/br/docs/hooks/functions/slot/slot_float.mdx @@ -0,0 +1,94 @@ +--- +title: slot_float +description: >- + Parse the STI_AMOUNT in the specified slot and return it as an XFL enclosed + number +--- +import { Tabs, TabItem } from '@astrojs/starlight/components'; + +### Behaviour + + + +* Parse the STI_AMOUNT in the specified slot and return it as an XFL enclosed number + + + +* Retrieves the bigint value associated with the specified slot. +* Returns an error code or the bigint value. + + + +### Definition + + + +```c +int64_t slot_float ( + uint32_t slot_no +); +``` + + + +```javascript +function slot_float(slotno: number): ErrorCode | bigint +``` + + + + + +### Example + + + +```c +int64_t xfl = + slot_float(amt_slot); +``` + + + + + +```javascript +const xfl = slot_float(amt_slot) +``` + + + + + +### Parameters + + + +| Name | Type | Description | +| -------- | --------- | --------------- | +| slot_no | uint32_t | The slot number | + + + +| Name | Type | Description | +| ------ | ------ | -------------------------------------------------- | +| slotno | number | The slot number to retrieve the bigint value from. | + + + +### Return Code + + + +| Type | Description | +| -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| int64_t |

The XFL enclosing number

If negative, an error:
DOESNT_EXIST
- the specified slot does not contain any object or it is an invalid slot

NOT_AN_AMOUNT
- the specified slot does not contain an STI_AMOUNT object

| + + + +| Type | Description | +| ------------------- | ------------------------------------------ | +| bigint or ErrorCode | Returns an error code or the bigint value. | + + + diff --git a/src/content/docs/br/docs/hooks/functions/slot/slot_set.mdx b/src/content/docs/br/docs/hooks/functions/slot/slot_set.mdx new file mode 100644 index 0000000..7340159 --- /dev/null +++ b/src/content/docs/br/docs/hooks/functions/slot/slot_set.mdx @@ -0,0 +1,105 @@ +--- +title: slot_set +description: Locate an object based on its keylet and place it into a slot +--- +import { Tabs, TabItem } from '@astrojs/starlight/components'; + +### Behaviour + + + +* Locate an object given the Keylet provided in `read_ptr` +* Emplace the located object into the slot specified or into a new slot if no slot (zero) is specified + + + +* Sets the data for the specified slot. +* Returns an error code or the result of the set operation. + + + + + +### Definition + + + +```c +int64_t slot_set ( + uint32_t read_ptr, + uint32_t read_len, + uint32_t slot_no +); +``` + + + + + +```javascript +function slot_set( + kl: ByteArray | HexString, + slotno: number + ): ErrorCode | number +``` + + + + + +### Example + + + +```c +int64_t slot_no = + slot_set(keylet, 34, 0); +``` + + + +```javascript +const slot_no = slot_set(keylet, 0) +``` + + + + + +### Parameters + + + +| Name | Type | Description | +| --------- | --------- | ----------------------------------------------------------------------------------------------- | +| read_ptr | uint32_t | Pointer to a buffer containing the keylet of the object to locate. This can also be a txn hash. | +| read_len | uint32_t | Length of the read buffer. Should always be 32 or 34. | +| slot_no | uint32_t | The slot number to emplace into, or 0 if you wish to pick the next available. | + + + +| Name | Type | Description | +| ------ | ---------------------- | --------------------------------------------------------- | +| kl | ByteArray \| HexString | The data to set in the slot, can be an array or a string. | +| slotno | number | The slot number to set data for. | + + + + + +### Return Code + + + +| Type | Description | +| -------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| int64_t |

The slot number the object was inserted into

If negative, an error:
OUT_OF_BOUNDS
- pointers/lengths specified outside of hook memory.

INVALID_ARGUMENT
- read_len must be either 32 or 34 bytes depending on whether a txn hash or a keylet is being used in read_ptr
- the hash or keylet was invalid

DOESNT_EXIST
- the requested object was not found

| + + + +| Type | Description | +| ------------------- | --------------------------------------------------------- | +| ErrorCode or number | Returns an error code or the result of the set operation. | + + + diff --git a/src/content/docs/br/docs/hooks/functions/slot/slot_size.mdx b/src/content/docs/br/docs/hooks/functions/slot/slot_size.mdx new file mode 100644 index 0000000..9515a99 --- /dev/null +++ b/src/content/docs/br/docs/hooks/functions/slot/slot_size.mdx @@ -0,0 +1,90 @@ +--- +title: slot_size +description: Compute the serialized size of an object in a slot +--- +import { Tabs, TabItem } from '@astrojs/starlight/components'; + +### Behaviour + + + +* Return the number of bytes the object in the specified slot occupies when serialized + + + +* Retrieves the size of the specified slot. + + + +### Definition + + + +```c +int64_t slot_size ( + uint32_t slot_no +); +``` + + + +```javascript +function slot_size(slotno: number): ErrorCode | number +``` + + + + + +### Example + + + +```c +int64_t bytes_needed = slot_size(1); // get size of slot 1 +``` + + + +```javascript +const bytes_needed = slot_size(1); // get size of slot 1 +``` + + + + + +### Parameters + + + +| Name | Type | Description | +| -------- | --------- | --------------- | +| slot_no | uint32_t | The slot number | + + + +| Name | Type | Description | +| ------ | ------ | ------------------------------------- | +| slotno | number | The slot number to check the size of. | + + + + + +### Return Code + + + +| Type | Description | +| -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| int64_t |

The number of bytes the object occupies when serialized

If negative, an error:
DOESNT_EXIST
- the specified slot does not contain any object or it is an invalid slot

| + + + +| Type | Description | +| ------------------- | ---------------------------------------------- | +| ErrorCode \| number | Returns an error code or the size of the slot. | + + + diff --git a/src/content/docs/br/docs/hooks/functions/slot/slot_subarray.mdx b/src/content/docs/br/docs/hooks/functions/slot/slot_subarray.mdx new file mode 100644 index 0000000..56d76d7 --- /dev/null +++ b/src/content/docs/br/docs/hooks/functions/slot/slot_subarray.mdx @@ -0,0 +1,107 @@ +--- +title: slot_subarray +description: Index into a slotted array and assign a sub-object to another slot +--- +import { Tabs, TabItem } from '@astrojs/starlight/components'; + +### Behaviour + + + +* Look up the array in slot `parent_slot` +* Retrieve the sub-object at the index specified in `array_id` +* Place sub-object into the slot `new_slot` or the next available slot if `new_slot` is 0. +* Return the new slot number. + + + +* Creates a subarray in the specified parent slot. +* Returns an error code or the result of the subarray creation. + + + +### Definition + + + +```c +int64_t slot_subarray ( + uint32_t parent_slot, + uint32_t array_id, + uint32_t new_slot +); +``` + + + +```javascript +function slot_subarray( + parent_slotno: number, + array_id: number, + new_slotno: number + ): ErrorCode | number +``` + + + + + +### Example + + + +```c +int64_t subslot = 0; +subslot = + slot_subarray(slot_no, i, (uint32_t)subslot); +``` + + + +```javascript +let subslot = 0 +subslot = slot_subarray(slot_no, i, subslot) +``` + + + + + +### Parameters + + + +| Name | Type | Description | +| ------------ | --------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| parent_slot | uint32_t | Slot the parent array is in | +| array_id | uint32_t |

The sf code of the field you are searching for.

To compute this manually take the serialized type and shift it into the 16 highest bits of uint32_t, then take the field and place it in the 16 lowest bits.

For example:
sfEmitNonce has type 5 and field 11 thus its value is 0x050BU

| +| new_slot | uint32_t | New slot number to place the object from the selected array index into. If null, choose the next available slot. _May be null._ | + + + +| Name | Type | Description | +| -------------- | ------ | --------------------------------------------- | +| parent_slotno | number | The parent slot number. | +| array_id | number | The ID of the array to create a subarray for. | +| new_slotno | number | The new slot number for the subarray. | + + + + + +### Return Code + + + +| Type | Description | +| -------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| int64_t |

The slot number of the newly allocated object

If negative, an error:

DOESNT_EXIST
- The specified array_id doesn't exist in the array pointed to by parent_slot

NO_FREE_SLOTS
- The API would require a new slot to be allocated but the Hook is already at the maximum number of slots.

NOT_AN_ARRAY
- The specified parent_slot does not contain an STArray.

| + + + +| Type | Description | +| ------ | ------------------------------------------------------------- | +| number | Returns an error code or the result of the subarray creation. | + + + diff --git a/src/content/docs/br/docs/hooks/functions/slot/slot_subfield.mdx b/src/content/docs/br/docs/hooks/functions/slot/slot_subfield.mdx new file mode 100644 index 0000000..4dfc8f9 --- /dev/null +++ b/src/content/docs/br/docs/hooks/functions/slot/slot_subfield.mdx @@ -0,0 +1,105 @@ +--- +title: slot_subfield +description: Index into a slotted object and assign a sub-object to another slot +--- +import { Tabs, TabItem } from '@astrojs/starlight/components'; + +### Behaviour + + + +* Look up the object in slot `parent_slot` +* Retrieve the sub-object at `field_id` +* Place sub-object into the slot `new_slot` or the next available slot if `new_slot` is 0. +* Return the new slot number. + + + +* Creates a subfield in the specified parent slot. +* Returns an error code or the result of the subfield creation. + + + +### Definition + + + +```c +int64_t slot_subfield ( + uint32_t parent_slot, + uint32_t field_id, + uint32_t new_slot +); +``` + + + +```javascript +function slot_subfield( + parent_slotno: number, + field_id: number, + new_slotno: number + ): ErrorCode | number +``` + + + + + +### Example + + + +```c +int64_t amt_slot = + slot_subfield(oslot, sfAmount, 0); +``` + + + +```javascript +const amt_slot = slot_subfield(oslot, sfAmount, 0) +``` + + + + + +### Parameters + + + +| Name | Type | Description | +| ------------ | --------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| parent_slot | uint32_t | Slot the parent object is in | +| field_id | uint32_t |

The sf code of the field you are searching for.

To compute this manually take the serialized type and shift it into the 16 highest bits of uint32_t, then take the field and place it in the 16 lowest bits.

For example:
sfEmitNonce has type 5 and field 11 thus its value is 0x050BU

| +| new_slot | uint32_t | New slot number to place the object from the selected field into. If null, choose the next available slot. _May be null._ | + + + +| Name | Type | Description | +| -------------- | ------ | --------------------------------------------- | +| parent_slotno | number | The parent slot number. | +| field_id | number | The ID of the field to create a subfield for. | +| new_slotno | number | The new slot number for the subfield. | + + + + + +### Return Code + + + +| Type | Description | +| -------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| int64_t |

The slot number of the newly allocated object

If negative, an error:

DOESNT_EXIST
- The searched for field isn't present in the parent slot or the parent slot is unfilled.

NO_FREE_SLOTS
- The API would require a new slot to be allocated but the Hook is already at the maximum number of slots.

INVALID_FIELD
- The specified field is not a valid sf field.

NOT_AN_OBJECT
- The slotted object is not a valid STObject.

| + + + +| Type | Description | +| ------------------- | ------------------------------------------------------------- | +| number or ErrorCode | Returns an error code or the result of the subfield creation. | + + + diff --git a/src/content/docs/br/docs/hooks/functions/slot/slot_type.mdx b/src/content/docs/br/docs/hooks/functions/slot/slot_type.mdx new file mode 100644 index 0000000..28ad034 --- /dev/null +++ b/src/content/docs/br/docs/hooks/functions/slot/slot_type.mdx @@ -0,0 +1,98 @@ +--- +title: slot_type +description: >- + Retrieve the field code of an object in a slot and, optionally, some other + information +--- +import { Tabs, TabItem } from '@astrojs/starlight/components'; + +### Behaviour + + + +* Locate the object pointed to by the specified `slot_no` +* Determine its `sf` field code and return this, or some other information (see below) if `flags` are used + + + +* Retrieves the type of the specified slot. +* Returns an error code or the type of the slot. + + + +### Definition + + + +```c +int64_t slot_type ( + uint32_t slot_no, + uint32_t flags +); +``` + + + +```javascript +function slot_type(slotno: number, flags: number): ErrorCode | number +``` + + + + + +### Example + + + +```c +int64_t fidle_code = + slot_type(1, 0); +``` + + + +```javascript +const field_code = slot_type(1, 0) +``` + + + + + +### Parameters + + + +| Name | Type | Description | +| -------- | --------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| slot_no | uint32_t | The slot number | +| flags | uin32_t |

For normal operation this should be 0.

To determine whether or not an STI_AMOUNT type contains a native (XAH) amount or a floating point (IOU) amount set to 1.

| + + + +| Name | Type | Description | +| ------ | ------ | ------------------------------------- | +| slotno | number | The slot number to check the type of. | +| flags | number | Flags to determine the type. | + + + + + +### Return Code + + + +| Type | Description | +| -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| int64_t |

If flags is 0 then:
The sf field code of the slotted object

If flags is 1 then:
1 if and only if the slotted object is an STI_AMOUNT and the type of the amount is XAH.

If negative, an error:
DOESNT_EXIST
- the specified slot_no does not contain an object.

NOT_AN_AMOUNT
- flags was set to 1 but the slotted object is not an STI_AMOUNT object

| + + + +| Type | Description | +| ------------------- | ---------------------------------------------- | +| ErrorCode or number | Returns an error code or the type of the slot. | + + + diff --git a/src/content/docs/br/docs/hooks/functions/slot/xpop_slot.mdx b/src/content/docs/br/docs/hooks/functions/slot/xpop_slot.mdx new file mode 100644 index 0000000..fe1e563 --- /dev/null +++ b/src/content/docs/br/docs/hooks/functions/slot/xpop_slot.mdx @@ -0,0 +1,89 @@ +--- +title: xpop_slot +description: Serialize and output the xpop transaction blob and metadata +--- +import { Tabs, TabItem } from '@astrojs/starlight/components'; + +### Behaviour + +* Locate the xpop blob on the `Import` transaction +* Emplace the located tx and meta objects into the slots specified + +### Definition + + + +```c +int64_t xpop_slot ( + uint32_t slot_no_tx, + uint32_t slot_no_meta +); +``` + + + + + +```javascript +function xpop_slot(slotno_tx: number, slotno_meta: number): ErrorCode | number +``` + + + + + +### Example + + + +```c +int64_t bytes_written = + xpop_slot(1, 2); // assumes a txn is slotted into slot=1 meta is slotted into slot=2 +``` + + + +```javascript +const bytes_written = xpop_slot(1, 2) +``` + + + + + +### Parameters + + + +| Name | Type | Description | +| -------------- | --------- | ---------------------------------------------- | +| slot_no_tx | uint32_t | The slot number to emplace the tx blob into. | +| slot_no_meta | uin32_t | The slot number to emplace the meta blob into. | + + + +| Name | Type | Description | +| ------------ | ------ | ----------------------------------- | +| slotno_tx | number | The transaction slot number to pop. | +| slotno_meta | number | The metadata slot number to pop. | + + + + + +### Return Code + + + +| Type | Description | +| -------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| int64_t |

PREREQUISITE_NOT_MET

- The originating tx type was not Import.

NO_FREE_SLOTS

- The API would require a new slot to be allocated but the Hook is already at the maximum number of slots.

| + + + +| Type | Description | +| ------------------- | --------------------------------------------------------- | +| number or ErrorCode | Returns an error code or the result of the pop operation. | + + + diff --git a/src/content/docs/br/docs/hooks/functions/state/state.mdx b/src/content/docs/br/docs/hooks/functions/state/state.mdx new file mode 100644 index 0000000..de5af89 --- /dev/null +++ b/src/content/docs/br/docs/hooks/functions/state/state.mdx @@ -0,0 +1,108 @@ +--- +title: state +description: >- + Retrieve the data pointed to by a Hook State key and write it to an output + buffer +--- +import { Tabs, TabItem, Aside } from '@astrojs/starlight/components'; + +### Behaviour + + + +* Read a 32 byte Hook State key from the `kread_ptr` +* Write the data (value) at that key to the buffer pointed to by `write_ptr` + + + +* Retrieves the Hook State value associated with the specified key. +* Returns an error code or the Hook State value for the key. + + + +### Definition + + + +```c +int64_t state ( + uint32_t write_ptr, + uint32_t write_len, + uint32_t kread_ptr, + uint32_t kread_len +); +``` + + + +```javascript +function state(key: ByteArray | HexString): ErrorCode | ByteArray +``` + + + + + +### Example + + + +```c +#define SBUF(str) (uint32_t)(str), sizeof(str) +if (state(SBUF(vault), SBUF(vault_key)) != 16) + rollback(SBUF("Error: could not read state!"), 1); +``` + + + +```javascript +const value = state(SBUF(vault), SBUF(vault_key)) +if (typeof value === 'number' || value.length != 16) + rollback("Error: could not read state!", 1); +``` + + + + + +### Parameters + + + +| Name | Type | Description | +| ---------- | --------- | ----------------------------------------------------------------- | +| write_ptr | uint32_t | A pointer to the buffer to write the data in the Hook State into. | +| write_len | uint32_t | The length of the write buffer. | +| kread_ptr | uint32_t | Pointer to a buffer containing the Hook State key. | +| kread_len | uint32_t | The length of the Hook State key. (Should be 32.) | + + + + + +| Name | Type | Description | +| ---- | ---------------------- | ----------------------------------------------------- | +| key | ByteArray or HexString | The key of the Hook State to retrieve the value from. | + + + + + +### Return Code + + + +| Type | Description | +| -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| int64_t |

The number of bytes written to the write buffer.

If negative, an error:
OUT_OF_BOUNDS
- pointers/lengths specified outside of hook memory.

DOESNT_EXIST
- the specified Hook State key doesn't have an associated value on the ledger at the time of the call.

TOO_BIG
- the key specified by read_ptr and read_len was larger than 32 bytes.

TOO_SMALL
- the output buffer was too small to store the Hook State data.

| + + + +| Type | Description | +| ---------------------- | ---------------------------------------------------------- | +| ByteArray or ErrorCode | Returns an error code or the Hook State value for the key. | + + + diff --git a/src/content/docs/br/docs/hooks/functions/state/state_foreign.mdx b/src/content/docs/br/docs/hooks/functions/state/state_foreign.mdx new file mode 100644 index 0000000..e058d90 --- /dev/null +++ b/src/content/docs/br/docs/hooks/functions/state/state_foreign.mdx @@ -0,0 +1,129 @@ +--- +title: state_foreign +description: >- + Retrieve the data pointed to, on another account, by a Hook State key and + write it to an output buffer +--- +import { Tabs, TabItem, Aside } from '@astrojs/starlight/components'; + +### Behaviour + + + +* Read a 20 byte Account ID from the `aread_ptr` +* Read a 32 byte Hook State key from the `kread_ptr` +* Write the data (value) at that key at that Account ID to the buffer pointed to by `write_ptr` + + + +* Retrieves the Foreign Hook State value belonging to another account for the specified key. +* Returns an error code or the Hook State value for the key. + + + +### Definition + + + +```c +int64_t state_foreign ( + uint32_t write_ptr, + uint32_t write_len, + uint32_t kread_ptr, + uint32_t kread_len, + uint32_t nread_ptr, + uint32_t nread_len, + uint32_t aread_ptr, + uint32_t aread_len +); +``` + + + +```javascript +function state_foreign( + key: ByteArray | HexString, + namespace: ByteArray | HexString | undefined | null, + accountid: ByteArray | HexString | undefined | null + ): ErrorCode | ByteArray +``` + + + + + +### Example + + + +```c +#define SBUF(str) (uint32_t)(str), sizeof(str) +uint8_t ns[32] = {0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0}; +int64_t lookup = + state_foreign(SBUF(blacklist_status), SBUF(otxn_accid), SBUF(ns), SBUF(blacklist_accid)); +if (lookup < 0) + rollback(SBUF("Error: could not find key on foreign state."), 1); +``` + + + +```javascript +const ns = [0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0] +const blacklist_status = + state_foreign(otxn_accid, ns, blacklist_accid) +if (typeof blacklist_status === 'number') + rollback("Error: could not find key on foreign state.", 1); +``` + + + + + +### Parameters + + + +| Name | Type | Description | +| ---------- | --------- | ------------------------------------------------------------------------------- | +| write_ptr | uint32_t | A pointer to the buffer to write the data in the Hook State into. | +| write_len | uint32_t | The length of the write buffer. | +| kread_ptr | uint32_t | Pointer to a buffer containing the Hook State key. | +| kread_len | uint32_t | The length of the Hook State key. (Should be 32.) | +| nread_ptr | uint32_t | A pointer to the buffer containing the 32 byte Namespace to lookup the state on | +| nread_len | uint32_t | The length of the namespace buffer (Should be 32). | +| aread_ptr | uint32_t | A pointer to a buffer containing the 20 byte Account ID to look up state on. | +| aread_len | uint32_t | The length of the Account buffer. (Should always be 20). | + + + + + +| Name | Type | Description | +| --------- | ---------------------- | ----------------------------------------------------- | +| key | ByteArray or HexString | The key of the Hook State to retrieve the value from. | +| namespace | ByteArray or HexString | The Hook namespace to look in. | +| accountid | ByteArray or HexString | The owner of the state. | +| | | | + + + + + +### Return Code + + + +| Type | Description | +| -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| int64_t |

The number of bytes written to the write buffer.

If negative, an error:
OUT_OF_BOUNDS
- pointers/lengths specified outside of hook memory.

DOESNT_EXIST
- the specified Hook State key doesn't have an associated value on the ledger at the time of the call.

TOO_BIG
- the key specified by read_ptr and read_len was larger than 32 bytes.

TOO_SMALL
- the output buffer was too small to store the Hook State data.

INVALID_ACCOUNT
- the account specified at aread_ptr is invalid or does not exist.

| + + + +| Type | Description | +| ---------------------- | ---------------------------------------------------------- | +| ErrorCode or ByteArray | Returns an error code or the Hook State value for the key. | + + + diff --git a/src/content/docs/br/docs/hooks/functions/state/state_foreign_set.mdx b/src/content/docs/br/docs/hooks/functions/state/state_foreign_set.mdx new file mode 100644 index 0000000..9dd333b --- /dev/null +++ b/src/content/docs/br/docs/hooks/functions/state/state_foreign_set.mdx @@ -0,0 +1,127 @@ +--- +title: state_foreign_set +description: Set the Hook State on another account for a given key, value and namespace +--- +import { Tabs, TabItem, Aside } from '@astrojs/starlight/components'; + +### Behaviour + + + +* Read a 32 byte Hook State key from the `kread_ptr` +* Read an arbitrary amount of data from `read_ptr` (the value) +* Read a 32 byte Namespace from the `nread_ptr` +* Read a 20 byte Account ID from `aread_ptr` +* Update the Hook State key on the specified account within the specified namespace with the value +* But only if a [Grant](https://xrpl-hooks.readme.io/docs/grants) on that account allows this. +* If the Hook Account is specified in `aread_ptr` then the behaviour is that of state_set but still allows specification of namespace through `nread_ptr` + + + +* Sets the Foreign Hook State with the specified value, key, namespace, and account ID. +* This operation requires authorization and a Grant to allow this action. +* Returns the number of bytes written to Hook State (the length of the data), negative on error. + + + +### Definition + + + +```c +int64_t state_foreign_set ( + uint32_t read_ptr, + uint32_t read_len, + uint32_t kread_ptr, + uint32_t kread_len, + uint32_t nread_ptr, + uint32_t nread_len, + uint32_t aread_ptr, + uint32_t aread_len +); +``` + + + +```javascript +function state_foreign_set( + value: ByteArray | HexString | undefined | null, + key: ByteArray | HexString, + namespace: ByteArray | HexString | undefined | null, + accountid: ByteArray | HexString | undefined | null + ): ErrorCode | number +``` + + + + + +### Example + + + +```c +#define SBUF(str) (uint32_t)(str), sizeof(str) +if (state_foreign_set(SBUF(vault), SBUF(vault_key), SBUF(namespace), SBUF(account)) < 0) + rollback(SBUF("Error: could not set foreign state!"), 1); +``` + + + +```javascript +if (state_foreign_set(vault, vault_key, namespace, account) < 0) + rollback("Error: could not set foreign state!", 1); +``` + + + + + +### Parameters + + + +| Name | Type | Description | +| ---------- | --------- | -------------------------------------------------------------------------------------------------------------------------------------------------------- | +| read_ptr | uint32_t |

Pointer to the data (value) to write into Hook State.
If this is 0 (null) then delete the data at this key. May be null.

| +| read_len | uint32_t |

The length of the data.
If this is 0 (null) then delete the data at this key. May be null.

| +| kread_ptr | uint32_t | A pointer to the Hook State key at which to store the value. | +| kread_len | uint32_t | The length of the key. (Should always be 32.) | +| nread_ptr | uint32_t | A pointer to the namespace which the key belongs to. | +| nread_len | uint32_t | The length of the namespace. (Should always be 32.) | +| aread_ptr | uint32_t | A pointer to the Account ID whose state we are trying to modify. | +| aread_len | uint32_t | The length of the Account ID. (Should always be 20.) | + + + + + +| Name | Type | Description | +| --------- | ---------------------- | ----------------------------------------------- | +| value | ByteArray or HexString | The value of data to persist. | +| key | ByteArray or HexString | The key of the Hook State to set the value for. | +| namespace | ByteArray or HexString | The Hook namespace to look in. | +| accountid | ByteArray or HexString | The owner of the state. | + + + + + +### Return Code + + + +| Type | Description | +| -------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| int64_t |

The number of bytes written to Hook State (the length of the data.)

If negative, an error:
OUT_OF_BOUNDS
- pointers/lengths specified outside of hook memory.

TOO_BIG
- kread_len was greater than 32, or
- read_len was greater than the maximum hook data size.

TOO_SMALL
- kread_len was 0.

NOT_AUTHORIZED
- no appropriate HookGrant was present on the foreign account to allow this state mutation.

PREVIOUS_FAILURE_PREVENTS_RETRY
- during this execution a previous state_foreign_set failed with NOT_AUTHORIZED, and consequently no further calls to this API are allowed during this execution.

| + + + +| Type | Description | +| ------------------- | ---------------------------------------------------------------------------------------------- | +| number or ErrorCode | Returns the number of bytes written to Hook State (the length of the data), negative on error. | + + + diff --git a/src/content/docs/br/docs/hooks/functions/state/state_set.mdx b/src/content/docs/br/docs/hooks/functions/state/state_set.mdx new file mode 100644 index 0000000..8df982e --- /dev/null +++ b/src/content/docs/br/docs/hooks/functions/state/state_set.mdx @@ -0,0 +1,119 @@ +--- +title: state_set +description: Set the Hook State for a given key and value +--- +import { Tabs, TabItem, Aside } from '@astrojs/starlight/components'; + +### Behaviour + + + +* Read a 32 byte Hook State key from the `kread_ptr` +* Read an arbitrary amount of data from `read_ptr` (the value) +* Update the Hook State key with the value + + + +* Sets the Hook State with the specified value and key. +* Returns the number of bytes written to Hook State (the length of the data), negative on error. + + + +### Definition + + + +```c +int64_t state_set ( + uint32_t read_ptr, + uint32_t read_len, + uint32_t kread_ptr, + uint32_t kread_len +); +``` + + + +```javascript +function state_set( + value: ByteArray | HexString | undefined | null, + key: ByteArray | HexString + ): ErrorCode | number +``` + + + + + +### Example + + + +```c +#define SBUF(str) (uint32_t)(str), sizeof(str) +if (state_set(SBUF(vault), SBUF(vault_key)) < 0) + rollback(SBUF("Error: could not set state!"), 1); +``` + + + + + +```javascript +const result = state_set(vault, vault_key) +if (result < 0) + rollback("Error: could not set state!", 1); +``` + + + + + + + +### Parameters + + + +| Name | Type | Description | +| ---------- | --------- | -------------------------------------------------------------------------------------------------------------------------------------------------------- | +| read_ptr | uint32_t |

Pointer to the data (value) to write into Hook State.
If this is 0 (null) then delete the data at this key. May be null.

| +| read_len | uint32_t |

The length of the data.
If this is 0 (null) then delete the data at this key. May be null.

| +| kread_ptr | uint32_t | A pointer to the Hook State key at which to store the value. | +| kread_len | uint32_t | The length of the key. (Should always be 32.) | + + + + + +| Name | Type | Description | +| ----- | ---------------------- | ----------------------------------------------- | +| value | ByteArray or HexString | The value of data to persist. | +| key | ByteArray or HexString | The key of the Hook State to set the value for. | + + + + + +### Return Code + + + +| Type | Description | +| -------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| int64_t |

The number of bytes written to Hook State (the length of the data.)

If negative, an error:
OUT_OF_BOUNDS
- pointers/lengths specified outside of hook memory.

TOO_BIG
- kread_len was greater than 32, or
- read_len was greater than the maximum hook data size.

TOO_SMALL
- kread_len was 0.

| + + + +| Type | Description | +| ------------------- | ---------------------------------------------------------------------------------------------- | +| number or ErrorCode | Returns the number of bytes written to Hook State (the length of the data), negative on error. | + + + diff --git a/src/content/docs/br/docs/hooks/functions/trace-debug/trace.mdx b/src/content/docs/br/docs/hooks/functions/trace-debug/trace.mdx new file mode 100644 index 0000000..fd17b03 --- /dev/null +++ b/src/content/docs/br/docs/hooks/functions/trace-debug/trace.mdx @@ -0,0 +1,99 @@ +--- +title: trace +description: Write the contents of a buffer to the Xahaud trace log +--- +import { Tabs, TabItem } from '@astrojs/starlight/components'; + +### Behaviour + +* Write a buffer from inside the Hook to the trace log along with a message (if any) + +### Definition + + + +```c +int64_t trace ( + uint32_t mread_ptr, + uint32_t mread_len, + uint32_t dread_ptr, + uint32_t dread_len, + uint32_t as_hex +); +``` + + + + + +```javascript +function trace( + message: string | null, + data: any, + hex: boolean | 0 | 1 + ): ErrorCode +``` + + + + + +### Example + + + +```c +#define SBUF(str) (uint32_t)(str), sizeof(str) +trace(SBUF("Buffer conatained"), SBUF(some_buffer), 1); +``` + + + +```javascript +trace("Buffer conatained", some_buffer, 1); +``` + + + + + +### Parameters + + + +| Name | Type | Description | +| ---------- | --------- | --------------------------------------------------------------------------------------------------- | +| mread_ptr | uint32_t | Pointer to a message to output before the buffer. _May be null._ | +| mread_len | uint32_t | Length of the message. _May be null._ | +| dread_ptr | uint32_t | Pointer to the buffer to output. | +| dread_len | uint32_t | Length of the buffer to output. | +| as_hex | uint32_t |

If 1 output the buffer as hex.
If 0 output the buffer as utf-8.

| + + + +| Name | Type | Description | +| ------- | ------- | -------------------------------------------------------------------- | +| message | string | The 'logging key', message to output before the buffer (can be null) | +| data | any | The data to log | +| hex | boolean |

Should it log formatted in HEX?

0 - NO
1 - YES

| + + + + + +### Return Code + + + +| Type | Description | +| -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- | +| int64_t |

0 if successful

If negative, an error:
OUT_OF_BOUNDS
- pointers/lengths specified outside of hook memory.

| + + + +| Type | Description | +| --------- | ------------------------------------------------------------------------------------------- | +| ErrorCode |

int64_t, value is 0 if successful

If negative, an error: OUT_OF_BOUNDS

| + + + diff --git a/src/content/docs/br/docs/hooks/functions/trace-debug/trace_float.mdx b/src/content/docs/br/docs/hooks/functions/trace-debug/trace_float.mdx new file mode 100644 index 0000000..93ba21f --- /dev/null +++ b/src/content/docs/br/docs/hooks/functions/trace-debug/trace_float.mdx @@ -0,0 +1,63 @@ +--- +title: trace_float +description: Write a XFL float to the Xahaud trace log +--- +import { Tabs, TabItem } from '@astrojs/starlight/components'; + +### Behaviour + +* Write a XFL floating point to the trace log along with a message (if any) + +### Definition + + + +```c +int64_t trace_float ( + uint32_t mread_ptr, + uint32_t mread_len, + int64_t float1 +); +``` + + + + + +### Example + + + +```c +#define SBUF(str) (uint32_t)(str), sizeof(str) +trace_float(SBUF("This is a float"), float_one()); +``` + + + + + +### Parameters + + + +| Name | Type | Description | +| ---------- | --------- | --------------------------------------------------------------------------------------------------------- | +| rmead_ptr | uint32_t | Pointer to a message to output before the hex-encoded serialized object found in the slot. _May be null._ | +| mread_len | uint32_t | Length of the message. _May be null._ | +| float1 | int64_t | The enclosing XFL integer. | + + + + + +### Return Code + + + +| Type | Description | +| -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- | +| int64_t |

0 if successful

If negative, an error:
OUT_OF_BOUNDS
- pointers/lengths specified outside of hook memory.

| + + + diff --git a/src/content/docs/br/docs/hooks/functions/trace-debug/trace_num.mdx b/src/content/docs/br/docs/hooks/functions/trace-debug/trace_num.mdx new file mode 100644 index 0000000..76a4d03 --- /dev/null +++ b/src/content/docs/br/docs/hooks/functions/trace-debug/trace_num.mdx @@ -0,0 +1,63 @@ +--- +title: trace_num +description: Write an integer to the Xahaud trace log +--- +import { Tabs, TabItem } from '@astrojs/starlight/components'; + +### Behaviour + +* Write an integer to the trace log along with a message (if any) + +### Definition + + + +```c +int64_t trace_num ( + uint32_t mread_ptr, + uint32_t mread_len, + int64_t number +); +``` + + + + + +### Example + + + +```c +#define SBUF(str) (uint32_t)(str), sizeof(str) +trace_num(SBUF("This is an integer"), 10); +``` + + + + + +### Parameters + + + +| Name | Type | Description | +| ---------- | --------- | --------------------------------------------------------------------------------------------------------- | +| rmead_ptr | uint32_t | Pointer to a message to output before the hex-encoded serialized object found in the slot. _May be null._ | +| mread_len | uint32_t | Length of the message. _May be null._ | +| number | int64_t | The number. | + + + + + +### Return Code + + + +| Type | Description | +| -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- | +| int64_t |

0 if successful

If negative, an error:
OUT_OF_BOUNDS
- pointers/lengths specified outside of hook memory.

| + + + diff --git a/src/content/docs/br/docs/hooks/functions/utilities/util_accid.mdx b/src/content/docs/br/docs/hooks/functions/utilities/util_accid.mdx new file mode 100644 index 0000000..bc98e45 --- /dev/null +++ b/src/content/docs/br/docs/hooks/functions/utilities/util_accid.mdx @@ -0,0 +1,110 @@ +--- +title: util_accid +description: Convert an r-address into a 20 byte Account ID +--- +import { Tabs, TabItem } from '@astrojs/starlight/components'; + +### Behaviour + + + +* Read an r-address from the `read_ptr` +* Write a 20 byte Account ID to the `write_ptr` + + + + + +* Read an r-address from the `raddress` +* Returns a 20 byte Account ID or an ErrorCode + + + + + +### Definition + + + +```c +int64_t util_accid ( + uint32_t write_ptr, + uint32_t write_len, + uint32_t read_ptr, + uint32_t read_len +); +``` + + + +```javascript +function util_accid(raddress: string): ErrorCode | ByteArray +``` + + + + + +### Example + + + +```c +uint8_t accid_out[20]; +uint8_t raddr_in[] = "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh"; + +int64_t bytes_written = + util_accid(accid_out, 20, raddr_in, sizeof(raddr_in)-1); +// NB: if specified as a c-string as above, account for the nul char +``` + + + + + +```javascript +const accId = util_accid('rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh') +``` + + + + + + + +### Parameters + + + +
NameTypeDescription
write_ptruint32_tPointer to a buffer of a suitable size to store the output Account ID. Must be at least 20 bytes.
write_lenuint32_tLength of the output buffer.
read_ptruint32_tPointer to the r-address.
read_lenuint32_tThe length of the r-address.
+ + + + + +
NameTypeDescription
raddressstringThe r-address to format as HEX account ID.
+ + + + + +### Return Code + + + +| Type | Description | +| -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| int64_t |

The number of bytes written (the length of the output r-address).

If negative, an error:
OUT_OF_BOUNDS
- pointers/lengths specified outside of hook memory.

INVALID_ARGUMENT
- read_ptr pointed at something which wasn't a valid r-address.

TOO_SMALL
- write_len was not large enough to store produced Account ID. (Should be 20 bytes).

TOO_BIG
- read_len was longer than an r-address can be.

| + + + + + + + +| Type | Description | +| --------------- | ------------------------------------------------------------------------------------------------ | +| string / number | If there is an error in formatting, otherwise returns the HEX Account ID as an array of numbers. | + + + diff --git a/src/content/docs/br/docs/hooks/functions/utilities/util_keylet.mdx b/src/content/docs/br/docs/hooks/functions/utilities/util_keylet.mdx new file mode 100644 index 0000000..f3c69f0 --- /dev/null +++ b/src/content/docs/br/docs/hooks/functions/utilities/util_keylet.mdx @@ -0,0 +1,148 @@ +--- +title: util_keylet +description: Compute a serialized keylet of a given type +--- +import { Tabs, TabItem, Aside, LinkButton } from '@astrojs/starlight/components'; + +### Concepts + +Slots and Keylets + + + +### Behaviour + +* Compute a keylet of the specified `keylet_type` according to the parameters `a` through `f` depending on type. +* Write the serialized 34 byte keylet into `write_ptr` + +### Definition + + + +```c +int64_t util_keylet ( + uint32_t write_ptr, + uint32_t write_len, + uint32_t keylet_type, + uint32_t a, + uint32_t b, + uint32_t c, + uint32_t d, + uint32_t e, + uint32_t f +); +``` + + + + + +```javascript +function util_keylet( + keylet_type: number, + accountid: ByteArray | HexString, + statekey: ByteArray | HexString, + namespace: ByteArray | HexString + ): ErrorCode | ByteArray +``` + + + + + +### Example + + + +```c +uint8_t keylet[34]; +if (util_keylet(keylet, 34, KEYLET_LINE, + hook_accid, 20, + account_field, 20, + currency_code, 20) != 34) + rollback("Keylet Failed.", 14, 1); +``` + + + + + +```javascript +if (util_keylet( + KEYLET_LINE, hook_accid, account_field, currency_code + ).length < 34) + rollback("Keylet Failed.", 1) +``` + + + + + +### Parameters + + + +
NameTypeDescription
write_ptruint32_tPointer to a buffer the serialized keylet will be written to
write_lenuint32_tLength of output buffer, should be at least 34.
keylet_typeuint32_tOne of the keylet types as defined in hookapi.h e.g. KEYLET_LINE for a trustline.
auint32_tSee keylet table below
buint32_tSee keylet table below
cuint32_tSee keylet table below
duint32_tSee keylet table below
euint32_tSee keylet table below
fuint32_tSee keylet table below
+ + + + + + + +
NameTypeDescription
keylet_typeThe type of the keylet to create
accountid(Optional) First piece of data for the keylet, can be an array of numbers, a string, or a number.
statekey(Optional) Second piece of data for the keylet, can be an array of numbers, a string, or a number.
namespace(Optional) Third piece of data for the keylet, can be an array of numbers, a string, or a number.
+ + + + + +### Keylet Table + + + +| Keylet Type | Parameters | +| ------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| KEYLET_HOOK_STATE |

a points to an Account ID
b is the length of the Account ID (should be 20)
c points to a hook state key
d is the length of the key (should be 32)
e points to a hook state namespace
f is the length of the namespace (should be 32)

| +|

KEYLET_AMENDMENTS
KEYLET_FEES
KEYLET_NEGATIVE_UNL
KEYLET_EMITTED_DIR

| `a`, `b`, `c`, `d`, `e`, `f` must all be zero | +| KEYLET_SKIP |

Either:
a, b, c, d, e, f all zero
Or:
a is a LedgerIndex
b is 1
c, d, e, f must all ​be zero

| +| KEYLET_LINE |

a points to the High Account ID
b is the length of the above (should be 20)
c points to the Low Account ID
d is the length of the above (should be 20)
e points to the Currency Code
f is the length of the above (should be 20)

| +| KEYLET_QUALITY |

a points to a serialized keylet
b is the length of the above (should be 34)
c is the high 32 bits of the uint64 to pass
d is the low 32 bits of the uint64 to pass
e, f must all be zero

| +| KEYLET_DEPOSIT_PREAUTH |

a points to an Account ID
b is the length (should be 20)
c points to an Account ID
d is the length (should be 20)
e, f must all be zero

| +|

KEYLET_UNCHECKED
KEYLET_CHILD
KEYLET_EMITTED_TXN

|

a points to a key.
b is the length of the key (should be 32.)
c, d, e, f must both ​be zero

| +|

KEYLET_OWNER_DIR
KEYLET_SIGNERS
KEYLET_ACCOUNT
KEYLET_HOOK

|

a points to an Account ID.
b is the length (should be 20.)
c, d, e, f must all be zero.

| +| KEYLET_PAGE |

a points to a key.
b is the length of the key (should be 32.)
c is the high 32 bits of the uint64 to pass
d is the low 32 bits of the uint64 to pass
e, f must both ​be zero

| +|

KEYLET_OFFER
KEYLET_CHECK
KEYLET_ESCROW
KEYLET_NFT_OFFER

|

a points to an Account ID.
b is the length (should be 20.)
And Either:
c is a 32bit unsigned integer (sequence)
d is 0
Or:
c points to a 32 byte key
d is the length of the key (32).
In both cases:
e and f must be 0.

| +| KEYLET_PAYCHAN |

a points to an Account ID
b is the length (should be 20)
c points to an Account ID
d is the length (should be 20)
And Either:
e 32bit unsigned int to pass
f is zero
Or:
e points to a 32 byte key
f is the length of the key (32)

| + + + + + + + + + + + +### Return Code + + + +| Type | Description | +| -------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| int64_t |

The number of bytes written, should always be 34.

If negative, an error:
OUT_OF_BOUNDS
- pointers/lengths specified outside of hook memory.

INVALID_ARGUMENT
- Call didn't comply with the above table.

TOO_SMALL
- Writing buffer was smaller than 34 bytes.

| + + + + + + + +| Type | Description | +| ------ | --------------------------------------------------------------------------------------------------------------------- | +| number | ErrorCode if there is an error in creating the keylet, otherwise returns the generated keylet as an array of numbers. | + + + diff --git a/src/content/docs/br/docs/hooks/functions/utilities/util_raddr.mdx b/src/content/docs/br/docs/hooks/functions/utilities/util_raddr.mdx new file mode 100644 index 0000000..d9b98d3 --- /dev/null +++ b/src/content/docs/br/docs/hooks/functions/utilities/util_raddr.mdx @@ -0,0 +1,106 @@ +--- +title: util_raddr +description: Convert a 20 byte Account ID to an r-address +--- +import { Tabs, TabItem } from '@astrojs/starlight/components'; + +### Behaviour + + + +* Read a 20 byte Account ID from the `read_ptr` +* Write the equivalent r-address for that Account ID to `write_ptr` + + + +* Read a 20 byte Account ID from the `accountid` +* Return the equivalent r-address for that Account ID + + + +### Definition + + + +```c +int64_t util_raddr ( + uint32_t write_ptr, + uint32_t write_len, + uint32_t read_ptr, + uint32_t read_len +); +``` + + + +```javascript +function util_raddr(accountid: ByteArray | HexString): ErrorCode | string +``` + + + + + +### Example + + + +```c +uint8_t raddr_out[40]; +uint8_t acc_id[20] = +{ + 0x2dU, 0xd8U, 0xaaU, 0xdbU, 0x4eU, 0x15U, + 0xebU, 0xeaU, 0xeU, 0xfdU, 0x78U, 0xd1U, 0xb0U, + 0x35U, 0x91U, 0x4U, 0x7bU, 0xfaU, 0x1eU, 0xeU +}; +int64_t bytes_written = + util_raddr(raddr_out, sizeof(raddr_out), acc_id, 20); +``` + + + + + +```javascript +const raddr = util_raddr('8D329C03074A98EF0488AB6ABBF5883F68CCFD4E') +// or +const raddr = util_raddr([ + 0x8D, 0x32, 0x9C, 0x03, 0x07, 0x4A, 0x98, 0xEF, 0x04, 0x88, + 0xAB, 0x6A, 0xBB, 0xF5, 0x88, 0x3F, 0x68, 0xCC, 0xFD, 0x4E +]) +``` + + + + + +### Parameters + + + + + +
NameTypeDescription
write_ptruint32_tPointer to a buffer of a suitable size to store the output r-address. Recommend at least 35 bytes.
write_lenuint32_tLength of the output buffer.
read_ptruint32_tPointer to the Account ID.
read_lenuint32_tThe length of the input. Always 20.
+ + + +
NameTypeDescription
accountidnumber[]/stringThe HEX account ID to return as r-address, can be provided as an array of numbers or a string.
+ + + +### Return Code + + + +| Type | Description | +| -------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| int64_t |

The number of bytes written (the length of the output r-address).

If negative, an error:
OUT_OF_BOUNDS
- pointers/lengths specified outside of hook memory.

INVALID_ARGUMENT
- read_len was not 20.

TOO_SMALL
- write_len was not large enough to store produced r-address in.

| + + + +| Type | Description | +| ------------- | ----------------------------------------------------------------------------------------- | +| string/number | ErrorCode if there is an error in formatting, otherwise returns the r-address as a string | + + + diff --git a/src/content/docs/br/docs/hooks/functions/utilities/util_sha512h.mdx b/src/content/docs/br/docs/hooks/functions/utilities/util_sha512h.mdx new file mode 100644 index 0000000..b7216ec --- /dev/null +++ b/src/content/docs/br/docs/hooks/functions/utilities/util_sha512h.mdx @@ -0,0 +1,98 @@ +--- +title: util_sha512h +description: Compute an sha512-half over some data +--- +import { Tabs, TabItem } from '@astrojs/starlight/components'; + +### Behaviour + + + +* Compute an `SHA512` hash over the data pointed to by `read_ptr` +* Write the first half of the hash to `write_ptr` + + + +* Compute an `SHA512` hash over the data pointed to by `data` +* Return the first half of the hash + + + +### Definition + + + +```c +int64_t util_sha512h ( + uint32_t write_ptr, + uint32_t write_len, + uint32_t read_ptr, + uint32_t read_len +); +``` + + + +```javascript +function util_sha512h(data: ByteArray | HexString): ErrorCode | ByteArray +``` + + + +### Example + +C + + + +```c +uint8_t hash_out[32]; +if (util_sha512h(hash_out, 32, data_in_ptr, data_in_len) < 0) + rollback("Could not generate Hash", 23, 1); +``` + + + + + +```javascript +if (util_sha512h(data) < 0) + rollback("Could not generate Hash", 1) +``` + + + + + +### Parameters + + + +
NameTypeDescription
write_ptruint32_tPointer to a buffer the hash will be written to
write_lenuint32_tLength of output buffer, should be at least 32.
read_ptruint32_tPointer to the buffer data will be read from (to compute the hash over)
read_lenuint32_tLength of input data
+ + + + + + + +
NameTypeDescription
dataByteArray or HexStringThe data to compute the hash over, can be provided as an array of numbers or a string.
+ + + + + +### Return Code + + + +
TypeDescription
int64_tThe number of bytes written, should always be 32.

If negative, an error:
OUT_OF_BOUNDS
- pointers/lengths specified outside of hook memory.

TOO_SMALL
- Output buffer isn't large enough
+ + + + + +
TypeDescription
ByteArrayErrorCode if there is an error in computing the hash, otherwise returns the SHA512-half hash as an array of numbers.
+ + + diff --git a/src/content/docs/br/docs/hooks/functions/utilities/util_verify.mdx b/src/content/docs/br/docs/hooks/functions/utilities/util_verify.mdx new file mode 100644 index 0000000..b1012a8 --- /dev/null +++ b/src/content/docs/br/docs/hooks/functions/utilities/util_verify.mdx @@ -0,0 +1,96 @@ +--- +title: util_verify +description: Verify a cryptographic signature +--- +import { Tabs, TabItem } from '@astrojs/starlight/components'; + +### Behaviour + +Verify a cryptographic signature + +* If the public key is prefixed with `0xED` then use `ED25519` +* Otherwise assume `SECP256k1` + +### Definition + + + +```c +int64_t util_verify ( + uint32_t dread_ptr, + uint32_t dread_len, + uint32_t sread_ptr, + uint32_t sread_len, + uint32_t kread_ptr, + uint32_t kread_len +); +``` + + + + + +```javascript +function util_verify( + signedData: ByteArray | HexString, + signature: ByteArray | HexString, + pubkey: ByteArray | HexString + ): 0 | 1 +``` + + + + + +### Example + + + +```c +if (!util_verify(payload_ptr, payload_len, + signature_ptr, signature_len, + publickey_ptr, publickey_len)) + rollback("Invalid Signature", 17, 60); +``` + + + +```javascript +if (util_verify(signedData,signature,pubkey)) + rollback("Invalid Signature", 60) +``` + + + + + +### Parameters + + + +
NameTypeDescription
dread_ptruint32_tPointer to the signed data
dread_lenuint32_tLength of the signed data
sread_ptruint32_tPointer to the signature
sread_lenuint32_tLength of the signature
kread_ptruint32_tPointer to the public key
kread_lenuint32_tLength of the public key
+ + + + + +
NameTypeDescription
signedDatanumber / stringThe signed data to verify, can be provided as an array of numbers or a string.
signaturenumber / stringThe signature to verify, can be provided as an array of numbers or a string.
pubkeynumber / stringThe public key responsible for the signature, can be provided as an array of numbers or a string.
+ + + + + +### Return Code + + + +
TypeDescription
int64_t0 - validation failed, the signature is invalid.
1 - validation succeeded, the signature is valid.

If negative, an error:
OUT_OF_BOUNDS
- pointers/lengths specified outside of hook memory.
+ + + + + +
TypeDescription
number0 - validation failed, the signature is invalid.
1 - validation succeeded, the signature is valid.
+ + + diff --git a/src/content/docs/br/docs/hooks/functions/websocket-apis/account_info.mdx b/src/content/docs/br/docs/hooks/functions/websocket-apis/account_info.mdx new file mode 100644 index 0000000..699c82b --- /dev/null +++ b/src/content/docs/br/docs/hooks/functions/websocket-apis/account_info.mdx @@ -0,0 +1,44 @@ +--- +title: account_info +--- +### New features + +The `account_info` API will now provide, in addition to its regular behaviour: + +* A list of namespaces currently in use by at least one Hook State Object +* A total count of all Hook State Objects the account has + +Example query: + +JSON + +```json +{ + "command": "account_info", + "account": "raaFre81618XegCrzTzVotAmarBcqNSAvK" +} +``` + +E.g. + +JSON + +```json +{ + "result": { + "account_data": { + "Account": "raaFre81618XegCrzTzVotAmarBcqNSAvK", + ..., + "HookNamespaces": [ + "01EAF09326B4911554384121FF56FA8FECC215FDDE2EC35D9E59F2C53EC665A0" + ], + "HookStateCount": 49, + ... + }, + "ledger_current_index": 5555046, + "validated": false + }, + "status": "success", + "type": "response" +} +``` diff --git a/src/content/docs/br/docs/hooks/functions/websocket-apis/account_namespace.mdx b/src/content/docs/br/docs/hooks/functions/websocket-apis/account_namespace.mdx new file mode 100644 index 0000000..056439b --- /dev/null +++ b/src/content/docs/br/docs/hooks/functions/websocket-apis/account_namespace.mdx @@ -0,0 +1,64 @@ +--- +title: account_namespace +--- +Use the `account_namespace` websocket API to query the Hook State Objects on a particular account in a particular namespace. + +Usage: + +JSON + +```json +{ + "command": "account_namespace", + "account": "", + "namespace_id": "" +} +``` + +Example query: + +JSON + +```json +{ + "command": "account_namespace", + "account": "raaFre81618XegCrzTzVotAmarBcqNSAvK", + "namespace_id": "01EAF09326B4911554384121FF56FA8FECC215FDDE2EC35D9E59F2C53EC665A0" +} +``` + +Example result: + +JSON + +```json +{ + "result": { + "account": "raaFre81618XegCrzTzVotAmarBcqNSAvK", + "ledger_current_index": 5554739, + "namespace_entries": [ + { + "Flags": 0, + "HookStateData": "CE66D3EBD1A91E9D6F47ADCF8890C92C3EE65A42313174682047656E20496E74656C28522920436F726528544D292069372D31313635473720322E3800080AF0000C3500000009C400000FA0", + "HookStateKey": "4556520237F1F3A48DFAED331FDB8F894522B5CE634C86A0258BA1B300000018", + "LedgerEntryType": "HookState", + "OwnerNode": "0", + "index": "065E103AC0838155A392DECA99D77FAE768EC822BFEC6BC999268ECBD16C8FAF" + }, + { + "Flags": 0, + "HookStateData": "00000000044E8000", + "HookStateKey": "4556520100000000000000000000000000000000000000000000000000000004", + "LedgerEntryType": "HookState", + "OwnerNode": "0", + "index": "0890BE9EE8CD129D21728FC3C2423CC0AB99D325A269A8A749C840F712989E5B" + }, + ... + ], + "namespace_id": "01EAF09326B4911554384121FF56FA8FECC215FDDE2EC35D9E59F2C53EC665A0", + "validated": false + }, + "status": "success", + "type": "response" +} +``` diff --git a/src/content/docs/br/docs/hooks/index.mdx b/src/content/docs/br/docs/hooks/index.mdx new file mode 100644 index 0000000..019ffd6 --- /dev/null +++ b/src/content/docs/br/docs/hooks/index.mdx @@ -0,0 +1,81 @@ +--- +title: Hooks +description: 'Introducing Hooks: The Smart Contract Functionality for Xahau.' +--- + +import { Aside } from '@astrojs/starlight/components'; + + + +### What are Hooks? + +Hooks allow the creation of customized logic and automation within the Xahau, making transactions smarter and more convenient. These small, efficient modules add custom on-ledger functionality, such as creating custom triggers for specific events on the ledger. + +These triggers can be used to send on-ledger actions or execute other actions in response to the specified event. Hooks are currently available on the [Xahau network](https://xahau.network/). + +> _To learn more about the theoretical concepts of Hooks you can visit the_ [_Concepts_](/docs/hooks/concepts/introduction) _section._ + +> _To learn how to code Hooks in C and its functions, visit_ [_Hooks C-Functions_](/docs/hooks/functions/overview/hook-api-conventions/)_._ + +> _There is a_ [_Hooks Builder site_](https://builder.xahau.network/) _where you can develop, test, debug, and deploy your own Hooks on testnet in your browser, using our examples or building your own from scratch._ + +> _[Hookstore](https://hookstore.xahau.network/) provides a platform for discovering, sharing, and managing Hooks. Use the [Hookstore Console](https://console.hookstore.xahau.network/) to manage your Hooks and explore the ecosystem._ + +> There is an upcoming development to allow writing Hooks in JavaScript, also known as JSHooks. At the moment it can be tested using [JSHooks](https://github.com/Xahau/jshooks-alpha) repo. + +### Why are Hooks a Big Deal? + +Simply put, Hooks add a robust smart contract functionality to Xahau, empowering you to construct and deploy applications with bespoke functionalities aligning with your specific needs and requirements. + +Hooks provide a versatile platform as they can be used for implementing a broad spectrum of business logic and smart contract paradigms. Once a hook is set up on an account, it enables you to do the following: + +* Block or allow transactions to and from the account. +* Change and keep track of the hook’s internal state and logic to inform programmatic choices. +* Autonomously initiate new transactions on the account’s behalf. + +Hooks can be written in C or any other preferred language and then compiled into WebAssembly. + +
+![Using Hooks Builder, you can develop, test, debug and deploy your own Hooks on our testnet, using our examples or building your own from scratch.](/assets/cdn.feather-2.webp) +
*Using Hooks Builder, you can develop, test, debug and deploy your own Hooks on our testnet, using our examples or building your own from scratch.*
+
+ +The Hooks Builder serves as an integrated development environment, facilitating the crafting, testing, debugging, and deployment of your Hooks on our testnet. + +Whether you're utilizing our examples or building from scratch, Hooks Builder provides a helpful environment for honing and deploying your smart contract solutions. + +### Some Examples of specific Hooks and Use Cases + +Showcasing the potential of Hooks with these concrete examples, each illustrating a unique application of smart contract functionality on Xahau: + +* **Auto-Savings Hook**: Automate savings by configuring a Hook to transfer a set amount of XAH to a separate savings account on the ledger. This could be done to help save a portion of XAH and build up savings at specified intervals—daily, weekly, or monthly. This recurring transfer mechanism can be a base for developing personal finance applications or subscription-based models. +* **Carbon-Offset Hook**: Each transaction triggers an additional transfer of 1% of the amount to a carbon offset account managed by a trusted non-governmental organization (NGO) using the money for a good cause. This feature can be used as a base for building applications that contribute to environmental sustainability with every transaction made. +* **Firewall Hook**: By filtering incoming and outgoing transactions. The Firewall Hook can block malicious transactions originating from known scam accounts or containing suspicious memos. By retrieving an updated blocklist from a Hook on a different account, the firewall maintains a robust defense against fraud without the need for manual intervention. Additionally, implementing spending limits to deny high-value unauthorized withdrawals could be a crucial feature for financial applications. + +### **Distinguishing Hooks from Ethereum Virtual Machine (EVM)** + +Xahau Hooks and the EVM allow developers to build and deploy custom logic and automation within their platforms. However, some key differences between these two technologies set them apart. + +* **Platform Compatibility**: Hooks are tailored for Xahau, while EVM smart contracts are designed for Ethereum-based blockchains. +* **Execution Efficiency**: Hooks utilize WebAssembly (WASM), outperforming the bytecode used by the EVM in terms of speed and efficiency. +* **Predictable Execution Time**: Xahau Hooks use guards to ensure maximum execution time is well-bounded and known ahead of time, improving efficiency. + +### Alternatives to Hooks on the XRPL ecosystem + +Ripple and Peersyst announced that an EVM-compatible sidechain is now live [on the company's devnet](https://opensource.ripple.com/docs/evm-sidechain/intro-to-evm-sidechain/). This sidechain functions as an autonomous blockchain, complete with its unique consensus protocol and transaction rules. The EVM sidechain is an alternative to Hooks, adding smart contract functionality to the ecosystem. + +However, it's essential to note that EVM sidechain contracts function on Layer 2, which requires a two-step process where XRP is transitioned onto the sidechain for contract execution and then back to the main ledger. Once on the sidechain, then again on the XRPL, meaning Layer 2 smart contracts cannot influence the flow. Hooks can decide if a transaction is allowed in the first place. Layer 2 can make a retroactive decision, but the initial transaction has already happened. + +Hooks are more closely integrated with XRPL, operating directly on Xahau, an Layer 1 XRPL-core fork, so they are more tightly integrated with the underlying blockchain technology than the EVM-compatible sidechain to take advantage of the specific features and capabilities of the XRPL platform. With the inherent scalability and performance of WebAssembly, Hooks are optimal to enhance Xahau's functionality. + +### Hooks Will Expand the On-ledger Functionality and Help Xahau Grow + +Hooks add native smart contract capabilities to Xahau, enabling the crafting of custom applications that meet the unique needs of users, bringing new functionalities, and opening up whole new domains of functionality. With Hooks, the possibilities are virtually unlimited. + +As Xahau continues to grow, there is no doubt that Hooks will play a significant role in driving further innovation and adoption of the platform by retail and enterprise users. diff --git a/src/content/docs/br/docs/index.mdx b/src/content/docs/br/docs/index.mdx new file mode 100644 index 0000000..5b9d2c8 --- /dev/null +++ b/src/content/docs/br/docs/index.mdx @@ -0,0 +1,28 @@ +--- +title: Documentação Xahau +--- + +import { LinkCard } from '@astrojs/starlight/components'; + +Bem-vindo à Documentação do Xahau. Este é o seu guia completo para entender e trabalhar com o Xahau. Esta documentação está dividida em três categorias principais: Funcionalidades, Infraestrutura e Técnico. + +Cada categoria foi desenvolvida para fornecer informações detalhadas e instruções sobre os diferentes aspectos do Xahau. + +### Funcionalidades + +A seção de Funcionalidades é onde você encontrará informações sobre os aspectos únicos do Xahau. Uma das áreas-chave abordadas nesta seção é a de Ferramentas para Desenvolvedores. + +Nossa página de Ferramentas para Desenvolvedores cobre Ferramentas de Hooks e Bibliotecas Cliente, simplificando o processo de interação com os Hooks e a Rede Xahau. Esta seção foi desenvolvida para ajudá-lo a entender as funcionalidades e capacidades do Xahau, com exemplos práticos para ilustrar essas características em ação. + +### Referência de Protocolo + +A seção de Referência de Protocolo da documentação do Xahau oferece uma análise aprofundada dos aspectos únicos da plataforma, incluindo vários tipos de transação como AccountDelete, CheckCancel e Payment, cada um com seu uso e características específicas. + +Também abrange os diferentes objetos do ledger essenciais para o funcionamento da rede, como AccountRoot e Amendments. Esta visão geral abrangente tem como objetivo aprimorar a compreensão das funcionalidades e capacidades do Xahau, garantindo que os usuários possam aproveitar ao máximo os recursos da rede. + +### Infraestrutura + +A infraestrutura é o núcleo da Rede Xahau. Os servidores que executam o software xahaud permitem que os usuários realizem ações como enviar, verificar e consultar transações. A documentação desta seção fornece instruções para instalar, atualizar, configurar e compilar o xahaud. Conceitos como atestar a identidade de um determinado servidor ou executar o xahaud como validador também são discutidos. + + +**Esperamos que esta documentação forneça as informações necessárias para entender, usar e contribuir com a Rede Xahau. Boa exploração!** diff --git a/src/content/docs/br/docs/infrastructure/advanced-configuration.mdx b/src/content/docs/br/docs/infrastructure/advanced-configuration.mdx new file mode 100644 index 0000000..4955258 --- /dev/null +++ b/src/content/docs/br/docs/infrastructure/advanced-configuration.mdx @@ -0,0 +1,57 @@ +--- +title: Configuração Avançada do xahaud +--- +Há inúmeras opções de configuração disponíveis para operadores do xahaud. Esta seção abordará algumas das opções mais comumente usadas, incluindo aquelas necessárias para clusterização de servidores e configuração de bancos de dados. + +Para documentação completa sobre opções de configuração, consulte os arquivos de configuração de exemplo no [repositório GitHub do xahaud](https://github.com/Xahau/xahaud/tree/dev/cfg). + +## Executando Bancos de Dados em Memória +Usuários que buscam maximizar o desempenho do xahaud podem optar por executar bancos de dados em memória, em vez de em mídia de armazenamento dedicada. Os bancos de dados em memória não são adequados para máquinas que armazenam histórico, pois os bancos de dados não são persistentes entre reinicializações do xahaud. Da mesma forma, a quantidade de histórico armazenado é contingente à memória do sistema disponível. Portanto, `online_delete` e `advisory_delete` são obrigatórios no `xahaud.cfg` para evitar erros de falta de memória. Ao usar um banco de dados em memória, é aconselhável desabilitar o SWAP, pois o SWAP grava o conteúdo da memória no disco, potencialmente anulando os benefícios obtidos ao armazenar o banco de dados em memória. + +Para habilitar o banco de dados em memória, edite o arquivo `xahaud.cfg`: + +``` +[relational_db] +type=RWDB + +[node_db] +type=RWDB # RWDB é o banco de dados em memória +online_delete=256 # Este valor deve ser baixo em máquinas que usam bancos de dados em memória. '256' é o valor mínimo. +advisory_delete=0 # Não requer intervenção humana para excluir histórico. Isso é necessário para evitar erros de falta de memória. +``` + +## Clusterização +A clusterização permite que operadores do xahaud configurem múltiplos servidores xahaud para que confiem uns nos outros, reduzindo a carga de trabalho. Servidores corretamente clusterizados podem compartilhar informações sobre conexões websocket, rpc e peer maliciosas ou problemáticas, além de propagar automaticamente transações enviadas por todo o cluster. Assim, se uma transação for enviada em um servidor com carga maior do que a taxa da transação permite, a transação ainda se propagará para outros servidores no cluster, aumentando a probabilidade de a transação ser incluída em um ledger futuro. + +Administradores que operam validadores xahaud podem se beneficiar da clusterização, pois o cluster fornece conectividade para o validador altamente seguro, eliminando a necessidade do validador conectar-se a servidores desconhecidos ou não confiáveis. + +Operadores de servidores não devem clusterizar seus servidores com servidores fora de seu próprio controle. Da mesma forma, servidores clusterizados devem ter conexões de baixa latência, idealmente localizados no mesmo data center. + +A geração de seeds de cluster (chaves públicas/privadas) é feita por meio do [método de API](/docs/features/http-websocket-apis/admin-api-methods) `validation_create`. Embora o nome do método inclua o termo 'validation', esse método não é usado para [criar as chaves](/docs/infrastructure/enabling-validation) usadas para assinar mensagens de validação. Em vez disso, é usado para criar chaves para identificar qualquer servidor xahaud, seja validador ou não. + +Para criar um cluster: +1. Em cada instância do xahaud que será incluída no cluster, gere uma chave pública e seed: `./xahaud validation_create` +2. Abra o arquivo `xahaud.cfg` de cada servidor e adicione ou edite as seguintes seções: + * `[ips_fixed]` - Inclua os endereços IPv4/6 e portas de escuta de peer (ex.: `10.1.1.2 21337`) para outros servidores que estarão no cluster. A porta de escuta é definida na stanza `[port_peer]` no arquivo `xahaud.cfg` do servidor que escuta conexões de entrada. A porta de escuta padrão para a Rede Xahau principal é `21337`. + * `[node_seed]` - A saída no campo `validation_seed` do comando `validation_create`. Esta é uma chave privada e deve ser instalada no mesmo servidor em que foi gerada. + * `[cluster_nodes]` - A saída do campo `validation_public_key` do comando `validation_create`. Esta é uma chave pública e deve ser instalada em servidores pares, não no servidor em que foi gerada. +3. Reinicie o xahaud em cada servidor do cluster: `systemctl restart xahaud` +4. Faça backup do `xahaud.cfg` de cada servidor. +5. Verifique a conectividade entre os pares clusterizados por meio do método de API [peers](/docs/features/http-websocket-apis/admin-api-methods): `./xahaud peers` + +A seção de cluster de um arquivo `xahaud.cfg` pode ser assim: +``` +[ips_fixed] +10.1.1.2 21337 # Par clusterizado 1 +10.1.1.3 21337 # Par clusterizado 2 +10.1.1.4 21337 # Par clusterizado 3 + +[cluster_nodes] +n9LzAHaB7ka318dAJWLQD1WkpGR86NyvaCzrtUAt4PuNtDCTCqxn # validation_public_key do par clusterizado 1 +n9KWNMsRdQ66jYHLCVgFBAQAzb16DwDioVdXSuV8pTcfEfaHkdvZ # validation_public_key do par clusterizado 2 +n9JFK8xUcy9S9TBmCcZKKmY28LEVjTurcpzC5XkXnyAAj1Svytee # validation_public_key do par clusterizado 3 + +[node_seed] +sn8QEFTpBM8nydnLD6FjxKN845uRG # validation_seed privado da instância xahaud local + +``` diff --git a/src/content/docs/br/docs/infrastructure/build-xahaud/index.mdx b/src/content/docs/br/docs/infrastructure/build-xahaud/index.mdx new file mode 100644 index 0000000..80163ae --- /dev/null +++ b/src/content/docs/br/docs/infrastructure/build-xahaud/index.mdx @@ -0,0 +1,45 @@ +--- +title: Compilar o xahaud +description: Configuração do Ambiente de Compilação e Compilação do xahaud +--- + +import { Aside } from '@astrojs/starlight/components'; + +Compilar software, como o xahaud, a partir do código-fonte disponível publicamente é um processo complexo que requer conhecimento aprofundado e experiência. Assim, existem múltiplas abordagens que os desenvolvedores podem adotar, dependendo do ambiente (ex.: Linux, MacOS, Windows). As instruções nos capítulos de documentação a seguir pretendem simplificar e expandir as do [repositório GitHub do xahaud](https://github.com/Xahau/xahaud/blob/dev/BUILD.md). Os desenvolvedores podem precisar desviar dessas instruções para realizar tarefas específicas ou garantir compatibilidade com sistemas operacionais específicos. + +Os artigos a seguir detalham o processo de configuração de um ambiente de compilação e a compilação do xahaud em vários ambientes de sistemas operacionais. + + + +## Compilando Software a Partir do Código-Fonte +Quando os desenvolvedores escrevem software, o fazem em linguagens de programação projetadas para serem legíveis por humanos. No entanto, não é eficiente para os computadores executar esse código legível por humanos. Portanto, há necessidade de o software ser "compilado" de código legível por humanos em bytecode que pode ser lido e interpretado rapidamente por um computador. + +Adicionando complexidade a este processo, os desenvolvedores frequentemente dependem de software escrito por outros desenvolvedores, chamado de "dependências", porque um pacote de software depende (requer) do outro. Para que essas dependências sejam incluídas no produto final, elas devem ser "vinculadas" ao código antes de sua compilação. O processo de vinculação pode ser muito intenso, pois as dependências do pacote de software original podem ter suas próprias dependências (que por sua vez podem ter ainda mais dependências, adicionando camadas). Os desenvolvedores dependem de ferramentas, como o Conan, para simplificar o processo de localização, configuração e vinculação de dependências. + +Todo o processo de garantir que as dependências sejam atendidas, compilar o software em um formato otimizado para máquina e executar testes no produto final é chamado de "build" (compilação). + +Como o xahaud é [publicado como software de código aberto no GitHub](https://github.com/Xahau/xahaud), qualquer pessoa pode visualizar, auditar, modificar, compilar e executar o código. Compilar a partir do código-fonte garante certeza de que o produto em execução está baseado no código-fonte publicamente visível, que também possui uma trilha de auditoria completa. Assim, operadores de validadores que priorizam um nível máximo de segurança devem considerar a compilação a partir do código-fonte. + +## Dependências + +Para compatibilidade, é importante observar as versões específicas do software usado no processo de compilação. O xahaud é escrito na linguagem C++20. + +Os requisitos atuais para compilar o xahaud incluem: + + +| Dependência | Versão | +| :---------- | :-------- | +| Python3 | >= 3.7 | +| GCC / G++ | >= 14.x | +| CMake | >= 3.16 | +| Conan2 | 2.x | +| openssl | 1.1.1 | +| boost | 1.86.0 | +| SQLite3 | 3.42.0 | +| Snappy* | 1.1.10 | +| SOCI* | 4.0.3 | +| WasmEdge* | 0.11.2 | + +\* Incluídas no repositório GitHub do Xahau/xahaud. diff --git a/src/content/docs/br/docs/infrastructure/build-xahaud/linux.mdx b/src/content/docs/br/docs/infrastructure/build-xahaud/linux.mdx new file mode 100644 index 0000000..f27138f --- /dev/null +++ b/src/content/docs/br/docs/infrastructure/build-xahaud/linux.mdx @@ -0,0 +1,365 @@ +--- +title: Instruções de Compilação para Linux +--- +import { Aside } from '@astrojs/starlight/components'; + + +Estas instruções foram projetadas para funcionar em distribuições baseadas em Debian (ex.: Ubuntu 22.04 e 24.04) e Red Hat Enterprise Linux (9 ou 10). Muitas instruções se sobrepõem, embora as diferenças entre sistemas operacionais sejam observadas ao longo do texto. São feitos esforços para testar as compilações em diferentes sistemas operacionais; no entanto, o Ubuntu é o ambiente mais testado e suportado para compilar e executar o xahaud. + +Para instruções adicionais, consulte o arquivo [BUILD.md](https://github.com/Xahau/xahaud/blob/dev/BUILD.md) no Repositório GitHub do Xahau/xahaud. + + + +## Instalar Dependências + +Usuários Debian/Ubuntu podem instalar as dependências necessárias usando estes comandos: +``` +sudo apt install -y git curl wget python3-pip python3-venv python3-dev ca-certificates gcc g++ build-essential cmake ninja-build libc6-dev libssl-dev libsqlite3-dev +``` + +Da mesma forma, usuários do RHEL 9 ou RHEL 10 podem instalar as dependências: +``` +sudo dnf install epel-release && sudo dnf update -y +sudo dnf config-manager --set-enabled crb -y +sudo dnf groupinstall "Development Tools" -y +sudo dnf install curl wget git ca-certificates cmake glibc-headers glibc-devel ninja-build perl-interpreter perl perl-FindBin sqlite-devel libstdc++ libstdc++-devel libstdc++-static gcc-c++ -y +``` + +## Clonar o Repositório GitHub do Xahau/xahaud +Antes de compilar, obtenha uma cópia local do repositório GitHub do xahaud: + +`git clone https://github.com/Xahau/xahaud.git` + +É possível compilar a partir de outros forks do repositório, basta ajustar a URL acima conforme necessário. + +### Selecionar o Branch do Repositório +O branch principal usado para o desenvolvimento do xahaud é `dev`. Usuários que preferem compilar a partir de um branch alternativo podem fazê-lo: + +`git checkout [nome do branch]` + +### Preparar o diretório de compilação +Crie um diretório dentro do repositório xahaud para armazenar os arquivos gerados durante o processo de compilação: + +`mkdir [/caminho/para/xahaud_github_repo]/.build` + +## Instalar e Configurar o Conan2 +1. Certifique-se de estar no diretório de compilação: `cd [/caminho/para/xahaud_github_repo]/.build` + +2. Crie um ambiente virtual Python3 (venv) no diretório `env`: `python3 -m venv env` + +3. Ative o ambiente virtual: `source ./env/bin/activate` + +4. Atualize o pip para que as versões mais recentes do software estejam disponíveis: `pip install --upgrade pip` + +5. Instale o Conan2: `pip install conan` + +6. Crie um novo perfil Conan2 (se ainda não o fez): `conan profile detect` + +7. Instale as receitas Conan para as dependências Snappy, SOCI e WasmEdge, incluídas no repositório GitHub do "xahaud": +``` +conan export external/snappy --version 1.1.10 --user xahaud --channel stable +conan export external/soci --version 4.0.3 --user xahaud --channel stable +conan export external/wasmedge --version 0.11.2 --user xahaud --channel stable +``` +8. Revise seu perfil Conan2, localizado em: `/home/[usuario]/.conan2/profiles/default`. Se necessário, adicione: +``` +[settings] +compiler.cppstd=20 +compiler.libcxx=libstdc++11 +``` +9. Pode ser necessário incluir as seguintes linhas no final do seu perfil Conan2: +``` +[conf] +tools.build:cxxflags=['-Wno-restrict'] +``` + +## Compilar o xahaud +1. Dentro do diretório `.build`, com o ambiente virtual Python3 ativo, ajuste "build_type" para "Release" ou "Debug" e execute o comando abaixo. É possível executar o comando duas vezes para gerar arquivos para cada "build_type". +``` +conan install .. --output-folder . --build missing --settings build_type=["Release" or "Debug"] -c tools.build:verbosity=verbose -c tools.compilation:verbosity=verbose +``` + +2. Se necessário, opções adicionais podem ser passadas ao Conan2: +``` +conan install .. --output-folder . --build missing --settings build_type=["Release" or "Debug"] -s compiler=gcc -s compiler.version=12 -s compiler.libcxx=libstdc++11 -s compiler.cppstd=20 -c tools.build:verbosity=verbose -c tools.compilation:verbosity=verbose -g VirtualBuildEnv -g VirtualRunEnv +``` + +3. Após a conclusão do Conan2, execute o cmake. Não especifique "DCMAKE_BUILD_TYPE" se estiver compilando a partir de múltiplas configurações (ambas "Release" e "Debug"). + +``` +cmake -DCMAKE_POLICY_DEFAULT_CMP0091=NEW \ + -DCMAKE_BUILD_TYPE=["Release" or "Debug"] \ + -DCMAKE_TOOLCHAIN_FILE:FILEPATH=build/generators/conan_toolchain.cmake \ + .. +``` + +4. Por fim, use o cmake para concluir o processo de compilação: `cmake --build . [adicione '--config Release' ou '--config Debug' se múltiplos tipos de compilação foram gerados]`. + +O arquivo de saída é chamado `rippled` e está localizado no diretório `.build`. Se múltiplos tipos de compilação (ambos "Release" e "Debug") foram especificados, o produto final estará localizado em: `.build/["Release" ou "Debug"]/rippled`. Renomeie o arquivo para 'xahaud' e mova-o para seu local final (tomando cuidado para não sobrescrever o repositório GitHub 'xahaud'). Marque o arquivo final como executável e baixe um arquivo de configuração e um arquivo de validadores conforme necessário. + +## Testar a Compilação +Para executar testes unitários: `./xahaud --unittest` + + +## Ambientes de Compilação para Iniciantes + +Manter diferentes ambientes de compilação (venvs Python3, perfis Conan2, etc.) é uma tarefa complexa, ainda mais porque os sistemas operacionais subjacentes frequentemente dependem ou esperam versões específicas do software. Assim, aqueles novos no processo de compilação podem se beneficiar do uso de contêineres ou da escrita de scripts bash usados em máquinas virtuais que reiniciam seu estado ao reiniciar. + +As subseções a seguir abordam os conceitos básicos de configuração de ambientes de compilação amnésicos e baseados em contêineres. + +### Contêineres +É possível usar o [Docker](https://docker.com) ou outros ambientes em contêineres (Podman, Kubernetes, etc.) para conter o processo de compilação, mantendo o sistema subjacente limpo. O uso de contêineres tem a vantagem adicional de testar facilmente compilações em múltiplos ambientes. Por exemplo, contêineres baseados em RHEL, Debian e outras distribuições podem ser configurados para usar diversas versões de compilador. Além disso, recursos como Dockerfiles Multistage permitem que os usuários compilem e depois implantem (executem) o xahaud usando um único Dockerfile. Os usuários também podem aproveitar o plugin `buildx` do Docker, que permite compilar para múltiplas plataformas simultaneamente. + +#### Instalar Docker +``` +# Debian/Ubuntu: +sudo apt update && sudo apt install docker.io docker-compose-v2 docker-buildx + +# RHEL (requer adicionar o repositório docker.com): +sudo dnf config-manager --add-repo https://download.docker.com/linux/rhel/docker-ce.repo +sudo dnf install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin +``` + +Após instalar, é possível adicionar sua conta de usuário local ao Docker, para que a interação com o Docker não exija acesso root/sudo: `sudo usermod -aG docker $USER`. Para que as alterações tenham efeito, você deve sair e fazer login novamente na sua sessão de usuário. + +#### Exemplo de Dockerfile +Para facilidade e consistência, é possível usar scripts Dockerfile (ex.: buildx, multistage, docker-compose v2, etc.) para configurar o ambiente de compilação e concluir o processo de compilação. + +Por exemplo, o xahaud pode ser compilado dentro de um contêiner Docker Ubuntu 24.04 usando um Dockerfile para descrever o contêiner, baixar e instalar dependências e compilar o produto final. Observe que o código a seguir segue os mesmos passos descritos anteriormente nesta página para o processo geral de compilação Linux; os passos são simplesmente aplicados dentro de um contêiner isolado. É possível adicionar variáveis adicionais ou ajustar o código a seguir para personalizar o processo de compilação. + +``` +# ~~~~ Arguments used to customize the container and build ~~~~ +ARG BASE_IMAGE=ubuntu:24.04 # Operating system for the build container +ARG REPO_URL=https://github.com/Xahau/xahaud # URL for the repository with the code to be compiled +ARG REPO_BRANCH=dev # Repository branch that will be used for the build +ARG RELEASE_TYPE=Release # Set to "Release" or "Debug" +ARG BASE_DIR=/build # Directory to build xahaud in + +# ~~~~ Initiate a container ~~~~ +FROM --platform=$BUILDPLATFORM ${BASE_IMAGE} AS builder + +ARG REPO_URL +ARG REPO_BRANCH +ARG RELEASE_TYPE +ARG BASE_DIR +ARG TARGETPLATFORM +ARG BUILDPLATFORM + +ENV DEBIAN_FRONTEND=noninteractive \ + CONAN2_DIR=/root/.conan2 + +# ~~~~ Install build dependencies ~~~~ +RUN set -ex; \ + if [ -f /etc/os-release ]; then . /etc/os-release; fi; \ + case " $ID $ID_LIKE " in \ + *debian*|*ubuntu*) \ + apt-get update && apt-get install -y -qq \ + git curl wget python3-pip python3-venv python3-dev ca-certificates \ + gcc g++ build-essential cmake ninja-build \ + libc6-dev libssl-dev libsqlite3-dev \ + && rm -rf /var/lib/apt/lists/* \ + ;; \ + *rhel*|*fedora*|*centos*|*rocky*|*alma*) \ + dnf install -y config-manager epel-release && dnf update -y && \ + dnf config-manager --set-enabled crb -y && \ + dnf groupinstall -y "Development Tools" && \ + dnf install -y curl wget git ca-certificates cmake glibc-headers glibc-devel \ + ninja-build perl-interpreter perl perl-FindBin sqlite-devel \ + libstdc++ libstdc++-devel libstdc++-static gcc-c++ python3-pip python3-devel \ + && dnf clean all \ + ;; \ + *) echo "Unsupported OS"; exit 1 ;; \ + esac + +# ~~~~ Clone the xahaud GitHub repository and create a '.build' directory ~~~~ +WORKDIR ${BASE_DIR} +RUN git clone ${REPO_URL} xahaud && \ + cd xahaud && \ + git checkout ${REPO_BRANCH} && \ + mkdir -p .build + +# ~~~~ Create a Python3 virtual environment and install Conan2 ~~~~ +RUN python3 -m venv ${BASE_DIR}/env && \ + . ${BASE_DIR}/env/bin/activate && \ + pip install --upgrade pip && \ + pip install conan + +# ~~~~ Configure Conan2 profile (the following assumes the user wishes to use cppstd version 20) ~~~~ +RUN . ${BASE_DIR}/env/bin/activate && \ + conan profile detect && \ + CONAN2_PROFILE="${CONAN2_DIR}/profiles/default" && \ + if grep -q '^compiler\.cppstd=' "$CONAN2_PROFILE"; then \ + sed -i 's/^compiler\.cppstd=.*/compiler.cppstd=20/' "$CONAN2_PROFILE"; \ + else \ + echo 'compiler.cppstd=20' >> "$CONAN2_PROFILE"; \ + fi && \ + if ! grep -Fqx "[conf]" "$CONAN2_PROFILE"; then \ + printf "[conf]\ntools.build:cxxflags=['-Wno-restrict']\n" >> "$CONAN2_PROFILE"; \ + fi + +# ~~~~ Export Conan recipies for snappy, soci, and wasmedge ~~~~ +RUN . ${BASE_DIR}/env/bin/activate && \ + cd ${BASE_DIR}/xahaud && \ + conan export external/snappy --version 1.1.10 --user xahaud --channel stable && \ + conan export external/soci --version 4.0.3 --user xahaud --channel stable && \ + conan export external/wasmedge --version 0.11.2 --user xahaud --channel stable + +# ~~~~ Build xahaud ~~~~ +RUN . ${BASE_DIR}/env/bin/activate && \ + cd ${BASE_DIR}/xahaud/.build && \ + conan install .. --output-folder . \ + --settings build_type=${RELEASE_TYPE} \ + --options *:shared=False \ + --build missing \ + -c tools.build:verbosity=verbose \ + -c tools.compilation:verbosity=verbose \ + -g VirtualBuildEnv \ + -g VirtualRunEnv && \ + cmake -DCMAKE_POLICY_DEFAULT_CMP0091=NEW \ + -DCMAKE_BUILD_TYPE=${RELEASE_TYPE} \ + -DBUILD_SHARED_LIBS=OFF \ + -DCMAKE_EXE_LINKER_FLAGS="-static-libgcc -static-libstdc++" \ + -DCMAKE_TOOLCHAIN_FILE:FILEPATH=build/generators/conan_toolchain.cmake \ + .. && \ + cmake --build . --parallel $(nproc) + +# ~~~~ Copy the config files to the BASE_DIR ~~~~ +RUN cp ${BASE_DIR}/xahaud/cfg/xahaud-example.cfg ${BASE_DIR}/xahaud.cfg && \ + cp ${BASE_DIR}/xahaud/cfg/validators-example.txt ${BASE_DIR}/validators-xahau.txt && \ + cp ${BASE_DIR}/xahaud/.build/rippled ${BASE_DIR}/rippled + + + +# ~~~~ Copy the xahaud.cfg and validators-xahau.txt files into the host OS ~~~~ +FROM scratch AS export +ARG BASE_DIR + +COPY --from=builder ${BASE_DIR}/rippled /xahaud +COPY --from=builder ${BASE_DIR}/xahaud.cfg /xahaud.cfg +COPY --from=builder ${BASE_DIR}/validators-xahau.txt /validators-xahau.txt + + + +# ~~~~ Create a Docker image with xahaud and configuration files ~~~~ +FROM ${BASE_IMAGE} AS runtime +ARG BASE_DIR +ENV DEBIAN_FRONTEND=noninteractive + +# ~~~~ Install runtime dependencies ~~~~ +RUN set -ex; \ + if [ -f /etc/os-release ]; then . /etc/os-release; fi; \ + case " $ID $ID_LIKE " in \ + *debian*|*ubuntu*) \ + apt-get update && apt-get install -y -qq \ + libssl3 libsqlite3-0 ca-certificates \ + && update-ca-certificates \ + && rm -rf /var/lib/apt/lists/* \ + ;; \ + *rhel*|*fedora*|*centos*|*rocky*|*alma*) \ + dnf install -y openssl-libs sqlite-libs ca-certificates \ + && dnf clean all && update-ca-trust \ + ;; \ + esac + +# ~~~~ Copy built binary and configs from builder ~~~~ +RUN mkdir -p /opt/xahaud/etc /opt/xahaud/bin /opt/xahaud/db /var/log/xahaud +COPY --from=builder ${BASE_DIR}/rippled /opt/xahaud/bin/xahaud +COPY --from=builder ${BASE_DIR}/xahaud.cfg /opt/xahaud/etc/xahaud.cfg +COPY --from=builder ${BASE_DIR}/validators-xahau.txt /opt/xahaud/etc/validators-xahau.txt + +# ~~~~ Create dicrectories and copy required shared libraries from builder ~~~~ +RUN --mount=type=bind,from=builder,source=/root/.conan2,target=/tmp/conan \ + find /tmp/conan -name "*.so*" -type f -exec cp {} /usr/local/lib/ \; && \ + ldconfig + +# ~~~~ Set permissions ~~~~ +RUN chmod -R 755 /opt/xahaud /var/log/xahaud + +WORKDIR /opt/xahaud + +# ~~~~ Expose ports ~~~~ +EXPOSE 5009 6009 50051 21337 21338 + +# ~~~~ Run xahaud ~~~~ +ENTRYPOINT ["/opt/xahaud/bin/xahaud"] +CMD ["--conf", "/opt/xahaud/etc/xahaud.cfg"] +``` + +O Dockerfile "multistage" acima pode ser usado para compilar o xahaud executando: + +`docker buildx build -t xahaud-builder --target builder --load .` + +Isso cria uma imagem Docker chamada "xahaud-builder" a partir do Dockerfile. O sinalizador `--target builder` interrompe o script no processo de compilação e o sinalizador `--load` importa a imagem resultante para o Docker. + +A imagem compilada também pode ser exportada para o sistema operacional host (junto com os arquivos de configuração): + +`docker buildx build --target export --output type=local,dest=$HOME .` + +Para executar o arquivo de compilação multistage e criar uma nova imagem Docker com o xahaud e os arquivos de configuração necessários: + +`docker buildx build --target runtime --load -t xahaud:latest .` + +A imagem resultante pode ser visualizada com: `docker images` e executada com: + +`docker run --rm -d --name xahaud -p 5009:5009 -p 6009:6009 -p 21337:21337 -v /home/$USER/xahaud/opt:/opt/xahaud -v /home/$USER/xahaud/log:/var/log/xahaud xahaud:latest` + +No comando acima, você pode ajustar o sinalizador `-d` para alternar a execução em modo desanexado, os sinalizadores `-p xxxx:xxxx` que definem os mapeamentos de porta, o sinalizador `--name xahaud` para alterar o nome do contêiner, e o sinalizador `-v /caminho/no/host:/caminho/no/container` para alterar onde os dados persistentes são armazenados no sistema operacional subjacente. Se executar em modo desanexado, os logs podem ser visualizados com `docker logs -f xahaud`. + +### Sistemas Operacionais Amnésicos + +Configurar um sistema Linux para esquecer completamente todo o software instalado ou modificado durante a execução fornece um caminho fácil para se recuperar de erros de compilação. Tipicamente, um sistema operacional amnésico é executado como uma máquina virtual com uma quantidade muito grande de memória disponível, pois todas as alterações são gravadas na memória em vez do disco. Compilar o xahaud pode exigir mais de 20 GB de memória, se todas as dependências/requisitos de software forem instalados em um sistema de arquivos de sobreposição baseado em memória. Tipicamente, é possível instalar a maioria das dependências de software (usando `apt` ou `dnf`) antes de tornar o sistema amnésico, reduzindo assim a memória necessária. + +#### Configurar um sistema operacional amnésico usando uma máquina virtual baseada em Debian +``` +# Instalar o pacote de software 'overlayroot' +apt update && apt install overlayroot + +# Atualizar o arquivo de configuração (/etc/overlayroot.conf) para habilitar um sistema de arquivos de sobreposição em memória. +sudo sed -i 's/^overlayroot=.*/overlayroot="tmpfs:swap=1,recurse=0"/' /etc/overlayroot.conf + +# Reconstruir initramfs +update-initramfs -u + +# Reinicializar na sobreposição +reboot + +# Após reinicializar, é possível remontar o sistema de arquivos de sobreposição com mais memória, já que apenas 50% da memória disponível é dedicada ao overlayfs por padrão. +# Ao redimensionar a memória, certifique-se de que alguma memória permaneça disponível para uso do sistema. O seguinte remontará com o overlayfs configurado para usar 30G de memória; ajuste conforme necessário. +# Também é possível usar um arquivo systemd para habilitar alterações persistentes no tamanho do overlayfs. +sudo mount -o remount,size=30G /media/root-rw +``` + +#### Configurar um sistema operacional amnésico usando uma máquina virtual baseada em RHEL +``` +# Garantir que o dracut esteja instalado +dnf install dracut -y + +# Configurar o dracut para suportar a sobreposição +printf 'add_drivers+=" overlay "\n' > /etc/dracut.conf.d/overlay.conf # Use esta linha para RHEL 9 +printf 'add_drivers+=" overlay "\nadd_dracutmodules+=" overlayfs "\n' > /etc/dracut.conf.d/overlay.conf # Use esta linha para RHEL 10 + +# Reconstruir +dracut -f + +# Atualizar a imagem de inicialização para usar uma sobreposição volátil systemd +grubby --update-kernel=ALL --args="systemd.volatile=overlay" +``` + +#### Compilando o xahaud +Uma vez que uma máquina virtual amnésica com memória suficiente tenha sido criada, é possível compilar o xahaud seguindo as instruções [acima nesta página](#_top). + +#### Desabilitando a amnésia +Instalar atualizações de software ou realizar outras tarefas que devem persistir exigirá que os usuários desabilitem a amnésia. Isso pode ser feito temporária ou permanentemente. Algumas atualizações de software requerem configuração adicional após uma reinicialização, portanto, é recomendado desabilitar a amnésia uma segunda vez ao reinicializar após uma atualização de software. + +Para desabilitar a amnésia em sistemas baseados em Debian: +1. Pressione `e` para editar a entrada de inicialização do Ubuntu. +2. Na linha que começa com "linux..." edite ou adicione a opção `overlayroot=` para ler `overlayroot=disabled`. Isso permitirá uma inicialização única em um sistema com armazenamento persistente. +3. Para desabilitar permanentemente a amnésia, execute `sudo sed -i '/^overlayroot=/c\overlayroot="disabled"' /etc/overlayroot.conf` para alterar `overlayroot="disabled"` no arquivo /etc/overlayroot.conf. Em seguida, atualize o initramfs: `sudo update-initramfs -u`. + +Para desabilitar a amnésia em sistemas baseados em RHEL 9/10: +1. Pressione `e` no menu de inicialização para editar as opções. +2. Remova a opção "systemd.volatile=overlay". +3. Pressione `F10` para inicializar. +4. Para desabilitar permanentemente a amnésia, execute `grubby --update-kernel=ALL --remove-args="systemd.volatile=overlay"` diff --git a/src/content/docs/br/docs/infrastructure/build-xahaud/macos.mdx b/src/content/docs/br/docs/infrastructure/build-xahaud/macos.mdx new file mode 100644 index 0000000..4f7bc44 --- /dev/null +++ b/src/content/docs/br/docs/infrastructure/build-xahaud/macos.mdx @@ -0,0 +1,9 @@ +--- +title: macOS +--- + +import { Aside } from '@astrojs/starlight/components'; + + diff --git a/src/content/docs/br/docs/infrastructure/enabling-validation.mdx b/src/content/docs/br/docs/infrastructure/enabling-validation.mdx new file mode 100644 index 0000000..adc7a73 --- /dev/null +++ b/src/content/docs/br/docs/infrastructure/enabling-validation.mdx @@ -0,0 +1,51 @@ +--- +title: Habilitar Validação no xahaud +--- +import { Aside } from '@astrojs/starlight/components'; + + +Os validadores são nós xahaud configurados com um par de chaves público/privado adicional, usado para assinar cada ledger proposto. Assim, os validadores são o principal mecanismo usado para alcançar consenso sobre a ordem em que as transações são aplicadas na Rede Xahau. + +## Considerações Preliminares +Executar um servidor xahaud de validação pode parecer simples; no entanto, há uma série de considerações para operadores de nós de produção, incluindo disponibilidade e segurança. As seções introdutórias a seguir fornecem contexto sobre essas considerações. + +### Segurança e Disponibilidade +Ao executar o xahaud como validador, a segurança e a disponibilidade do sistema são críticas. Os operadores de validadores devem monitorar ativamente seus servidores e responder rapidamente a interrupções. Alguns operadores de validadores optam por hospedar máquinas de espera em data centers diversos, para que possam se recuperar rapidamente de interrupções. Embora seja possível hospedar um validador confiável em casa, é improvável que tal configuração possa fornecer estabilidade e segurança suficientes para que o validador ganhe confiança mais ampla (ex.: inclusão em UNLs publicadas). Da mesma forma, os operadores de validadores são fortemente desencorajados de executar software diferente do xahaud em uma máquina usada como validador xahaud, pois isso aumenta a probabilidade de falta de recursos ou exposição de uma vulnerabilidade de segurança. Administradores de sistema que exigem acesso websocket ou RPC a um servidor são encorajados a executar máquinas diferentes para consultas, para que os recursos não sejam desviados da tarefa crítica de validar ledgers. +

+O par de chaves de validação privado/público deve ser armazenado e com backup em um ambiente seguro e offline. Qualquer pessoa com acesso às chaves de um validador confiável tem potencial para prejudicar a rede. Após instalar um token de validação no arquivo xahaud.cfg, é aconselhável restringir o acesso de leitura (`chmod 400 xahaud.cfg`) e alterar a propriedade do arquivo para "root" ou "xahaud", dependendo do tipo de instalação (`chown root:root xahaud.cfg`). + +### Atestação de Identidade +Para evitar um [ataque Sybil](https://en.wikipedia.org/wiki/Sybil_attack) e construir confiança, os nós xahaud de validação atestam sua identidade assinando criptograficamente um nome de domínio com suas chaves de validação. Esta assinatura é então hospedada no mesmo domínio, em um [arquivo no formato TOML](/docs/infrastructure/identity). Além de verificar a identidade de um validador, este arquivo TOML também pode ser usado para verificar a identidade de titulares de contas individuais na Rede Xahau, fornecendo um atestado assinado pela chave privada da conta em vez da chave privada de validação. O arquivo TOML deve ser hospedado em um servidor web com criptografia TLS habilitada em:

https://[seu-dominio.com]/.well-known/xahau.toml

+ +### Peering +Para manter um alto nível de segurança, os nós xahaud configurados como validadores devem conectar-se apenas com pares conhecidos e confiáveis. Habilitar a configuração `peer_private` e definir explicitamente `ips_fixed` no arquivo xahaud.cfg forçará um servidor a conectar-se apenas a pares definidos. Proteções no nível do sistema operacional e hardware, como firewalls, fornecem garantia adicional de que o servidor está conectando-se apenas a pares definidos. No entanto, isso pode ser um desafio, pois validadores com poucos pares, tipicamente menos de cinco, correm o risco de perder sincronização com o restante da rede. + +### Governança e Confiança +A Rede Xahau utiliza o [Jogo de Governança](/docs/features/governance-game) como método democrático para gerenciar a Rede. Adicionalmente, cada instância xahaud participante da Rede é obrigada a instalar uma lista de servidores de validação confiáveis, chamada de Lista de Nós Únicos ou UNL. Assim, os participantes de governança existentes podem votar para incluir um novo validador em uma cadeira na mesa de governança. Separadamente, publicadores de UNL confiáveis, como o [InFTF](https://inftf.org), podem escolher incluir um validador em sua lista recomendada de validadores confiáveis. Executar um validador não garante inclusão no Jogo de Governança ou em qualquer UNL. Tipicamente, os servidores de validação selecionados para inclusão no processo de governança têm: +1. Alta disponibilidade + - Monitoramento efetivo 24/7/365 com respostas rápidas a interrupções +2. Alta concordância com o restante da rede +3. Um proprietário/operador identificado e uma localização geográfica clara +4. Uma abordagem proativa para atualizar e votar em [emendas](/docs/features/amendments) e taxas + - Isso requer dedicar tempo para acompanhar o que está em desenvolvimento + +## Habilitando a Validação +Converter um servidor xahaud padrão em validador é um processo simples. Essencialmente, os usuários irão gerar um par de chaves público/privado, que é então usado para gerar um token usando uma chave efêmera derivada do par mestre. Esse token é instalado no arquivo `xahaud.cfg`, instruindo o xahaud a propor validações à Rede. + +### Compilando a Ferramenta de Chaves de Validação +No momento, não há uma versão binária oficial do software usado para gerar chaves de validação. Assim, os usuários podem compilar a ferramenta do zero ou depender de compilações não oficiais. As instruções para compilar a ferramenta são as mesmas que as instruções para [compilar o xahaud](../build-xahaud), e são fornecidas na página do repositório [Xahau/validator-keys-tool](https://github.com/Xahau/validator-keys-tool). Também há alguns [binários empacotados](https://github.com/jscottbranson/xahau-examples/) disponíveis em repositórios não oficiais. Usuários que buscam gerar chaves para validadores de produção devem compilar a ferramenta do zero em uma máquina segura e com air gap. + +Embora o xahaud forneça o [Método de API Admin](/docs/features/http-websocket-apis/admin-api-methods) `validation_create`, este método NÃO é capaz de gerar o token de validação necessário ou permitir a verificação de domínio. Assim, apesar do nome, o método `validation_create` é usado para criar chaves público/privadas para identificar um servidor de forma geral, por exemplo ao [clusterizar múltiplos servidores](/docs/infrastructure/advanced-configuration). + +### Gerando e Instalando Chaves de Validação +Considere usar uma máquina offline para gerar chaves de validação e um token de validação. +1. Navegue até o diretório contendo a ferramenta de chaves de validação: `cd [/caminho/para/ferramenta]` +2. Gere um novo par de chaves: `./validator-keys create_keys` +3. O par de chaves recém-gerado é armazenado em `/home/[usuario]/[.ripple or .xahaud]/validator-keys.json`. O caminho de armazenamento depende de qual versão do validator-keys-tool é usada. +4. Idealmente, os validadores devem fornecer atestação de identidade. Para isso, defina seu domínio no arquivo validator-keys.json: `./validator-keys set_domain [exemplo.com]` + - Se não desejar fornecer um domínio de identificação, gere um token de validação sem domínio: `./validator-keys create_token --keyfile /home/[usuario]/.xahaud/validator-keys.json` +5. Revise a saída do comando anterior. Anote o `[validator_token]`, pois ele será instalado no xahaud.cfg para habilitar a validação. Se um domínio foi definido, anote a linha `attestation=""`, pois ela precisará ser adicionada ao arquivo TOML servido em seu domínio. + - Sempre que a ferramenta é usada para gerar um novo `validator_token`, um campo `token_sequence` é incrementado no arquivo `validator-keys.json`. A Rede ignorará validações de qualquer servidor que tenha um token gerado com um número de sequência menor que o mais alto número observado. Por exemplo, se seu token de validação tiver o número de sequência "3" e você gerar um novo token com número de sequência "2", as validações de qualquer máquina usando o novo token com o número de sequência mais baixo serão ignoradas. Esse recurso permite que operadores de servidores gerem um novo token, em vez de gerar novas chaves de validação mestre, em caso de comprometimento de segurança ou outro incidente. +6. Abra o xahaud.cfg e cole o `[validation_token]`, depois reinicie o serviço xahaud. +7. Cole o `attestation=""` em seu arquivo [TOML](/docs/infrastructure/identity) para provar a identidade do seu validador. +8. Certifique-se de que as chaves de validação privadas estejam armazenadas com segurança, idealmente separadas do validador. diff --git a/src/content/docs/br/docs/infrastructure/identity.mdx b/src/content/docs/br/docs/infrastructure/identity.mdx new file mode 100644 index 0000000..8b57f18 --- /dev/null +++ b/src/content/docs/br/docs/infrastructure/identity.mdx @@ -0,0 +1,179 @@ +--- +title: Servir um Arquivo TOML para Verificação de Identidade +--- +***A verificação de identidade requer duas partes. NUNCA CONFIE APENAS EM ARQUIVOS TOML OU ATESTAÇÕES DE VALIDADOR/CONTA NA REDE PARA CONFIRMAR IDENTIDADE, POIS QUALQUER PESSOA PODE DEFINI-LOS. Um site (URL) deve reivindicar a propriedade do validador/conta, e os dados na rede devem corresponder.*** + +Dado que a confiança é fundamental para a Rede Xahau, é ideal que entidades operando validadores xahaud recebam crédito por seus servidores. A atestação de identidade fornece aos usuários garantias de que uma entidade não está ganhando controle desproporcional sobre os validadores confiáveis (UNL padrão) na Rede. Isso é feito publicando duas atestações: uma de um servidor de validação na Rede Xahau e uma segunda de um servidor web que serve o domínio identificador via TLS. Assim, o validador reivindica associação com o domínio web e o domínio web reivindica associação com o validador. *Sem ambas as reivindicações, não é possível confiar na atestação de identidade.* + +Da mesma forma, titulares de contas Xahau individuais podem querer publicar um arquivo TOML atestando que contas específicas na rede estão sob seu controle. As atestações de propriedade de conta são particularmente relevantes para empresas, como exchanges ou instituições financeiras. Como acontece com os validadores, essas atestações requerem duas partes: um servidor web que reivindica a propriedade de um endereço da Rede Xahau, bem como um endereço de conta na rede que afirma ser de propriedade do mesmo domínio. As atestações de conta fornecem aos usuários confiança de que estão roteando depósitos para o endereço correto. + +O conteúdo e a estrutura deste arquivo são semelhantes aos usados pelo [Stellar](https://developers.stellar.org/docs/tokens/publishing-asset-info) e pelo [XRP Ledger](https://xrpl.org/docs/references/xrp-ledger-toml). Como o arquivo pode conter campos personalizados, é importante permitir flexibilidade ao criar ferramentas projetadas para analisar o arquivo TOML. + +## Configuração do Servidor Web e DNS +1. O conteúdo do arquivo deve estar no [formato TOML](https://github.com/toml-lang/toml). +2. O arquivo TOML deve ser servido a partir de: `https://[subdominio-opcional.seu-dominio.com]/.well-known/xahau.toml` + * O caminho `/.well-known/xahau.toml` não deve ser alterado. O caminho deve estar em letras minúsculas. + * [RFC 5785](https://datatracker.ietf.org/doc/html/rfc5785) contém mais informações sobre o caminho "/.well-known/". +3. Um certificado TLS encadeado a uma autoridade certificadora confiável deve ser usado para criptografar as conexões que servem o arquivo TOML. +4. O DNS Sec é recomendado para o domínio. +5. Subdomínios podem ser usados para servir o arquivo, e arquivos idênticos podem ser hospedados em múltiplos subdomínios. +6. O tipo de conteúdo do arquivo é `application/toml`. +7. O arquivo TOML deve ser servido com um cabeçalho CORS: `Access-Control-Allow-Origin: *` +8. Cabeçalhos adicionais podem ser servidos com o arquivo TOML, se necessário. +9. Campos personalizados ou não padrão podem ser adicionados ao arquivo TOML, conforme exigido por usuários individuais. +10. Nenhum campo é estritamente obrigatório no arquivo TOML. + +### Configuração CORS +Apache: +``` + + Header set Access-Control-Allow-Origin "*" + +``` +Nginx: +``` +location /.well-known/xahau.toml { + add_header 'Access-Control-Allow-Origin' '*'; +} +``` + +### Conteúdo do Arquivo TOML +Os arquivos TOML são tipicamente subdivididos em seções que descrevem o próprio arquivo TOML (metadados), responsáveis (partes responsáveis) e ativos reivindicados, incluindo: validadores, servidores xahaud não validadores, contas e moedas emitidas. + +#### Exemplo de TOML +O exemplo abaixo tem como objetivo ilustrar todas as seções comumente incluídas em um arquivo TOML da Rede Xahau. Usuários individuais podem não ter todas essas seções em seu arquivo TOML, e alguns usuários podem precisar incluir múltiplas seções iguais. Por exemplo, se uma exchange emite múltiplas moedas, incluiria uma seção `[[CURRENCIES]]` para cada IOU emitido na Rede. +``` +[METADATA] +modified = 2025-08-04T14:24:34.123Z +expired = 2025-12-31T14:24:34.123Z + +[ORGANIZATION] +name = "A Company B.V." +website = "https://example.com" +email = "contact@example.com" + +[[PRINCIPALS]] +name = "A. Person" +email = "a_person@example.com" +social_1 = "https://www.linkedin.com/company/incfintech" +x = "@IncFinTech" + +[[VALIDATORS]] +public_key = "nHBixLw8q7XUP5AKceK2aZriN67PPjQW7JJ7hLkJgxvkTTs5go6k" +attestation = "07FA61020CA5E0605BE29D213DCC33F934B631EB6215F52D3E99D8AEA841272E300758B5C03CD2332190307324B4869838B77BAD275B31CF59D13E8FA6A8780B" +owner_country = "US" +server_country = "CA" +network_asn = "398726" +network = "21337" +unl = "https://vl.xahau.org" + +[[SERVERS]] +ws = "wss://" +json_rpc = "https://" +peer = "https://" +network = "21337" + +[[ACCOUNTS]] +address = "rabc..." +network = "21337" +desc = "This wallet is used for client deposits." + +[[CURRENCIES]] +code = "USD" +issuer = "rabc..." +symbol = "$" +network = "21337" +display_decimals = 2 + +[[CURRENCIES]] +code = "EUR" +issuer = "rabc..." +symbol = "€" +network = "21337" +display_decimals = 2 +``` + +#### Metadados +Datas/horas no arquivo TOML devem ser especificadas em UTC e incluir precisão de milissegundos. Por exemplo, `2025-08-04T14:24:34.123Z`. Apenas uma seção de metadados pode ser incluída em um arquivo TOML. + + + + +
CampoTipo de DadoDescrição
`modified`Data-HoraData e hora em que o TOML foi modificado mais recentemente.
`expires`Data-HoraApós esta data/hora, o arquivo TOML será considerado expirado e, portanto, inválido.
+ +#### Organização +Se uma entidade, em vez de um indivíduo, está assumindo responsabilidade pelo arquivo TOML, essa entidade deve usar esta seção para se identificar. Seria incomum e provavelmente um erro que um arquivo TOML tivesse múltiplas seções `[ORGANIZATION]`. Se múltiplas seções forem necessárias, certifique-se de adicionar um conjunto adicional de colchetes: `[[ORGANIZATION]]`. + + + + + + +
CampoTipo de DadoDescrição
`name`StringO nome da organização que hospeda o arquivo TOML.
`email`StringEndereço de e-mail da organização.
`website`StringSite da organização (tipicamente este é o mesmo que a URL onde o TOML está hospedado).
`social_[x]`StringLink para um perfil de mídia social. Este campo não é padronizado no momento. Assim, `x = "@IncFinTech"` e `social_1 = https://x.com/IncFinTech` são ambos válidos.
+ +#### Responsáveis +Esta seção é usada para identificar pontos de contato individuais para a infraestrutura da Rede Xahau e/ou contas. + + + + + + +
CampoTipo de DadoDescrição
`name`StringO nome de um indivíduo responsável por supervisionar as operações na Rede Xahau da organização.
`email`StringEndereço de e-mail do responsável.
`website`StringSite do responsável.
`social_[x]`StringLink para um perfil de mídia social. Este campo não é padronizado no momento. Assim, `x = "@IncFinTech"` e `social_1 = https://x.com/IncFinTech` são ambos válidos.
+ +#### Validadores +Os operadores de validadores são fortemente encorajados a publicar uma atestação como prova de propriedade. Fornecer informações geográficas e de ISP é importante, pois permite que publicadores de listas confiáveis (dUNL) avaliem a diversidade geográfica dos validadores confiáveis na rede. Se muitos validadores confiáveis estiverem concentrados em uma região geográfica ou em um ASN de rede, há risco para a rede como um todo. + + + + + + + + + +
CampoTipo de DadoDescrição
`public_key`StringA chave pública mestre usada para validações.
`attestation`StringAtestação de domínio gerada pela ferramenta validator-keys.
`owner_country`StringCódigo de país [ISO-3166-2](https://en.wikipedia.org/wiki/ISO_3166-2) para a entidade ou pessoa responsável pelo servidor.
`server_country`StringCódigo de país ISO-3166-2 para a localização física do servidor.
`network_asn`StringO Número de Sistema Autônomo (ASN) do(s) Provedor(es) de Serviços de Internet que fornecem conectividade à internet para o servidor.
`network`StringIdentifica qual rede (Mainnet, Testnet, etc.) o servidor participa.
`unl`StringUma URL hospedando a lista de validadores confiáveis que o validador assina.
+ +#### Servidores +Participantes da rede que fornecem peering público ou acesso a API via websocket ou RPC podem publicar detalhes para acessar servidores individuais. + + + + + + +
CampoTipo de DadoDescrição
`ws`StringA URL para acesso público via websocket. Começa com "ws:// ou wss://".
`json_rpc`StringA URL para acesso público via RPC. Começa com "http:// ou https://".
`peer`StringURL que outros servidores podem usar para fazer peering com o servidor identificado no TOML.
`network`StringIdentifica qual rede (Mainnet, Testnet, etc.) o servidor participa.
+ +#### Contas +Entidades que precisam de verificação de conta podem usar esta seção para reivindicar propriedade de uma determinada carteira da Rede Xahau. + + + + + +
CampoTipo de DadoDescrição
`address`StringA chave pública codificada (começando com `r`) que identifica uma carteira da Rede Xahau.
`network`StringIdentifica qual rede (Mainnet, Testnet, etc.) a carteira é usada.
`desc`StringDescrição legível por humanos do para que a carteira é usada.
+ +#### Moedas +É possível que múltiplas carteiras emitam moedas com o mesmo código de moeda. ***Assim, é crítico que os usuários verifiquem a carteira emissora, além do código de moeda.*** + + + + + + + +
CampoTipo de DadoDescrição
`code`StringO símbolo de ticker do token como três dígitos ou 40 caracteres hexadecimais. Este campo diferencia maiúsculas de minúsculas.
`issuer`StringO endereço da carteira (começando com `r`) que emitiu a moeda. A carteira referenciada deve estar presente na seção `[[ACCOUNTS]]` do arquivo TOML.
`symbol`StringO símbolo (ex.: "$") usado para identificar a moeda.
`network`StringIdentifica qual rede (Mainnet, Testnet, etc.) a moeda é emitida.
`display_decimals`InteiroO número de dígitos à direita do ponto decimal que os clientes devem exibir ao mostrar quantidades da moeda.
+ +## Verificação de Domínio do Validador +Hospedar o arquivo `xahau.toml` permite que proprietários de domínio reivindiquem a propriedade de um validador. No entanto, é crítico que o validador também reconheça essa propriedade, para que terceiros possam confiar de forma confiável nos operadores de rede. Como os validadores formam a espinha dorsal do progresso na Rede Xahau, é importante que os operadores protejam adequadamente suas chaves de validação privadas. + +Se você não está familiarizado com a Ferramenta de Chaves de Validador, consulte a página sobre [Habilitando a Validação no xahaud](/docs/infrastructure/enabling-validation). + +Usuários que já concluíram as etapas na página Habilitando a Validação não precisam repeti-las. Basta colar o campo `attestation = ""` no arquivo TOML e garantir que o `[validator_token]` correto esteja instalado no `xahaud.cfg`. + +Usuários que não configuraram um domínio quando geraram inicialmente um token de validação podem fazê-lo executando `./validator-keys set_domain [exemplo.com]`. Antes de tentar definir o domínio, certifique-se de que o arquivo JSON da chave de validação mestre esteja armazenado no caminho correto: `/home/[usuario]/[.ripple or .xahaud]/validator-keys.json`. + +## Verificação de Endereço de Carteira +Consistente com a verificação de domínio do validador, verificar a propriedade de um endereço de carteira na Rede Xahau requer dois componentes: um arquivo TOML servido por uma conexão criptografada com TLS (com um certificado devidamente encadeado) do domínio que reivindica a propriedade e uma transação do endereço da carteira verificando a reivindicação de propriedade. Para reivindicar a propriedade de um endereço de carteira: +1. Inclua o endereço como uma seção `[[accounts]]` no arquivo TOML. +2. Envie uma [transação AccountSet](/docs/protocol-reference/transactions/transaction-types/accountset) com o campo `Domain` especificado. diff --git a/src/content/docs/br/docs/infrastructure/installing-xahaud.mdx b/src/content/docs/br/docs/infrastructure/installing-xahaud.mdx new file mode 100644 index 0000000..a451e78 --- /dev/null +++ b/src/content/docs/br/docs/infrastructure/installing-xahaud.mdx @@ -0,0 +1,214 @@ +--- +title: Instalar o xahaud +description: >- + O software por trás do Xahau é de código aberto, e qualquer pessoa pode executar um nó localmente. Os usuários podem executar um contêiner Docker, uma instância local ou um arquivo binário. +--- +import { Aside } from '@astrojs/starlight/components'; + +Ao executar um nó, os usuários precisarão configurar as definições com base em se o nó será executado na rede de teste ou na rede principal. Ao fazer a transição de um único nó de uma rede para outra, os arquivos de banco de dados devem ser apagados, exceto wallet.db, que contém as credenciais de identidade do servidor. + +As técnicas mais comuns para instalar o xahaud são localmente usando systemd ou dentro de um contêiner, como Docker. + + + +## Processo de Instalação no Linux +Independentemente de como o xahaud é instalado (Docker ou em todo o sistema), o processo geral é semelhante em sistemas Linux. +As seções a seguir, [Contêiner Docker](#docker-container-install-script) e [Instalação Local](#local-install-script), aproveitam scripts bash, que automatizam as seguintes etapas: + +1. Obter o binário do xahaud: + - Baixar uma imagem binária compilada de [https://build.xahau.tech](https://build.xahau.tech) + - [Compilar a partir do código-fonte](/docs/infrastructure/build-xahaud/) +2. Obter os arquivos de configuração: + - [xahaud.cfg](https://raw.githubusercontent.com/Xahau/xahaud/refs/heads/dev/cfg/xahaud-example.cfg) + - [validators-xahau.txt](https://raw.githubusercontent.com/Xahau/xahaud/refs/heads/dev/cfg/validators-example.txt) +3. Se desejado, criar um usuário e grupo xahaud, que pode ser proprietário do binário e outros arquivos relevantes: + - `sudo groupadd --system xahaud` + - `sudo useradd --system --gid xahaud --no-create-home xahaud` +4. Decidir (e criar) uma estrutura de diretórios para armazenar: + - O binário do xahaud. O padrão é tipicamente: `/opt/xahaud/bin/xahaud` + - Dois arquivos de configuração do xahaud, `xahaud.cfg` e `validators-xahau.txt`. O padrão é: `/etc/xahaud/`, embora `/opt/xahaud/etc/` seja frequentemente usado. Esses dois locais podem ser vinculados simbolicamente. + - Os bancos de dados do xahaud. O padrão é frequentemente: `/opt/xahaud/db/` + - Um local para arquivo de log, como: `/var/log/xahaud/default.log` +5. Mover o binário e os arquivos de configuração do xahaud para seus lugares na estrutura de diretórios. +6. Editar o `xahaud.cfg` para que os caminhos na configuração correspondam aos caminhos na estrutura de diretórios. +7. Se necessário, alterar as permissões de propriedade. Se executar o xahaud como validador, é importante restringir o arquivo `xahaud.cfg`, pois ele contém o token de validação. + - `chown -R xahaud:xahaud /opt/xahaud /var/log/xahaud` + - `chmod -R 750 /opt/xahaud /var/log/xahaud` +8. Criar um arquivo de serviço systemd (como o exemplo [abaixo](#example-systemd-service-file)) para executar o xahaud como um daemon. + - O arquivo está localizado em: `/etc/systemd/system/xahaud.service` + - Após criar ou editar o arquivo, execute: `systemctl daemon-reload` + - Para executar o xahaud automaticamente na inicialização do sistema: `systemctl enable --now xahaud` + - Se preferido, o xahaud pode ser executado sem o systemd: `/caminho/para/xahaud --conf=/caminho/para/xahaud.cfg` +9. Criar um wrapper para executar comandos do xahaud sem precisar especificar o caminho completo. + - Tipicamente armazenado em `/usr/local/bin/xahaud` + - O conteúdo pode ser: `exec ${XAHAUD_DIR}xahaud --conf=${CONF_DIR}xahaud.cfg "$@"` + +### Exemplo de Arquivo de Serviço systemd +O seguinte arquivo de serviço deve ser modificado com base na estrutura de diretórios e permissões de propriedade selecionadas pelo usuário. +``` +[Unit] +Description=Xahaud Daemon +After=network-online.target +Wants=network-online.target + +[Service] +Type=simple +ExecStart=/path/to/xahaud --silent --conf=/path/to/xahaud.cfg +Restart=on-failure +User=xahaud +Group=xahaud +LimitNOFILE=65536 + +[Install] +WantedBy=multi-user.target +``` + +### Exemplo de Script de Instalação Linux +Um script bash básico usado para instalar o xahaud. Este script segue as instruções fornecidas anteriormente nesta seção. +``` +### VARIABLES ### + +#### Directory structure #### +XAHAUD_DIR="/opt/xahaud/bin/" # Path where xahaud binary will be stored +CONF_DIR="/opt/xahaud/etc/" # Path where the xahaud.cfg and validators-xahau.txt will be stored +DB_DIR="/opt/xahaud/db/" # Path where xahaud will store databases +LOG_DIR="/var/log/xahaud/" # Path where logfile(s) will be stored. + +#### Ownership #### +XAHAUD_USER="xahaud" # User that owns the xahaud process. + +#### Download links #### +BINARY_URL="https://build.xahau.tech/2025.9.8-HEAD%2B2194" # URL to the xahaud binary that will be downloaded. +CFG_URL="https://raw.githubusercontent.com/Xahau/xahaud/refs/heads/dev/cfg/xahaud-example.cfg" # This will be renamed to 'xahaud.cfg' +VAL_URL="https://raw.githubusercontent.com/Xahau/xahaud/refs/heads/dev/cfg/validators-example.txt" # This will be renamed to 'validators-xahau.txt' + + + +########## SCRIPT BEGINS HERE. DO NOT ADJUST VARIABLES BELOW THIS LINE ########## + +### CREATE DIRECTORIES #### +echo "Checking directory structure." +sudo mkdir -p ${XAHAUD_DIR} ${CONF_DIR} ${DB_DIR} ${LOG_DIR} + +### CREATE xahaud GROUP AND USER ### +echo "Checking for user and group." +if ! getent group ${XAHAUD_USER} > /dev/null; then + sudo groupadd --system ${XAHAUD_USER} +fi + +if ! getent passwd ${XAHAUD_USER} > /dev/null; then + sudo useradd --system --gid ${XAHAUD_USER} --no-create-home ${XAHAUD_USER} +fi + +### DOWNLOAD CONFIGURATION FILES ### +echo "Downloading files." +if [[ ! -f "${CONF_DIR}xahaud.cfg" ]]; then + curl -fsSL ${CFG_URL} -o ${CONF_DIR}xahaud.cfg +fi +if [[ ! -f "${CONF_DIR}validators-xahau.txt" ]]; then + curl -fsSL ${VAL_URL} -o ${CONF_DIR}validators-xahau.txt +fi + +### DOWNLOAD xahaud ### +if [[ ! -f "${XAHAUD_DIR}xahaud" ]]; then + curl -fsSL ${BINARY_URL} -o ${XAHAUD_DIR}xahaud +elif [[ -f "${XAHAUD_DIR}xahaud" ]]; then + echo "Existing xahaud binary found. It will be renamed to 'xahaud.old'." + mv ${XAHAUD_DIR}xahaud ${XAHAUD_DIR}xahaud.old + curl -fsSL ${BINARY_URL} -o ${XAHAUD_DIR}xahaud +fi + +### CHANGE OWNERSHIP AND PERMISSIONS ### +echo "Checking ownership and permissions." +sudo chown -R ${XAHAUD_USER}:${XAHAUD_USER} ${XAHAUD_DIR} ${CONF_DIR} ${DB_DIR} ${LOG_DIR} +sudo chmod -R 0750 ${XAHAUD_DIR} ${CONF_DIR} ${DB_DIR} ${LOG_DIR} + +### Install systemd SERVICE FILE ### +if [[ ! -f "/etc/systemd/system/xahaud.service" ]]; then +echo "Installing system service file." +sudo cat > /etc/systemd/system/xahaud.service < /usr/local/bin/xahaud <git clone [url-do-repositorio] +2. Navegue até o diretório do repositório: cd [nome-do-repositorio] +3. Execute: ./build +4. Execute: ./up +5. Comandos e informações adicionais estão localizados no arquivo README.md no repositório Docker. Os arquivos de configuração e bancos de dados estão localizados no diretório `store` dentro do diretório Docker. + +## Script de Instalação Local +Os repositórios Docker do Xahau (Mainnet e Testnet) contêm um script para automatizar o processo de instalação local, para que o xahaud possa ser executado fora do Docker. Esses scripts são semelhantes ao [Resumo da Instalação Linux](#linux-install-process), pois criarão arquivos systemd, um usuário 'xahaud' e arquivos de configuração padrão. As URLs para esses scripts estão na tabela no final desta página. Para instalar localmente: + +1. Baixe e execute o script de instalação: curl -sL [https://link-para-script] | bash +2. Edite o arquivo de configuração: /opt/xahahud/etc/xahaud.cfg +3. Verifique e, se necessário, edite o conteúdo do arquivo de validadores confiáveis: /opt/xahaud/etc/validators-xahau.txt +4. Inicie e habilite o xahaud para ser executado automaticamente: systemctl enable --now xahaud +5. Verifique se o xahaud está em execução: /opt/xahaud/bin/xahaud server_info + +## Recursos, Peering e Configurações +Este peering é relevante tanto para contêineres Docker quanto para instalações locais. + + + + + + + + + + + + + + + + + + + + + + +
RecursoRede PrincipalRede de Teste
Documentação e Recursoshttps://xahau.network/Mesmo que a Mainnet
Documentação de Contratos Inteligentes Hookshttps://xahau.network/docs/hooks/Mesmo que a Mainnet
Explorerhttps://explorer.xahau.network/https://explorer.xahau-test.net
URL WebSocket Públicawss://xahau.networkwss://xahau-test.net
ID de Rede e Porta de Escuta de Peer21337 porta atribuída pela IANA21338
Servidores de Peering e Bootstrapbacab.alloy.ee 21337

hubs.xahau.as16089.net 21337		79.110.60.122 21338

79.110.60.124 21338

79.110.60.125 21338

79.110.60.121 21338



2a0c:3bc0::1c74 21338

2a0c:3bc0::169d 21338

2a0c:3bc0::1aaf 21338

2a0c:3bc0::1d78 21338
Contêiner Dockerhttps://github.com/Xahau/mainnet-dockerhttps://github.com/Xahau/Xahau-Testnet-Docker
Scripts de Instalação Localhttps://raw.githubusercontent.com/Xahau/mainnet-docker/refs/heads/main/xahaud-install-update.shhttps://github.com/Xahau/Xahau-Testnet-Docker/blob/main/xahaud-install-update.sh
Versões Bináriashttps://build.xahau.techMesmo que a Mainnet
Arquivo de Configuração de Exemplohttps://github.com/Xahau/xahaud/blob/dev/cfg/xahaud-example.cfghttps://github.com/Xahau/Xahau-Testnet-Docker/blob/main/store/etc/xahaud.cfg
Arquivo de Validadores Confiáveis (UNL) de Exemplohttps://github.com/Xahau/xahaud/blob/dev/cfg/validators-example.txthttps://github.com/Xahau/Xahau-Testnet-Docker/blob/main/store/etc/validators-xahau.txt
Arquivos de Configuração Documentadoshttps://github.com/Xahau/xahaud/tree/dev/cfgMesmo que a Mainnet
Ações de Compilação do GitHub (números de versão)https://github.com/Xahau/xahaud/actions?query=branch%3Arelease+is%3Asuccess+build+using+dockerMesmo que a Mainnet
diff --git a/src/content/docs/br/docs/infrastructure/interacting.mdx b/src/content/docs/br/docs/infrastructure/interacting.mdx new file mode 100644 index 0000000..c7fdddc --- /dev/null +++ b/src/content/docs/br/docs/infrastructure/interacting.mdx @@ -0,0 +1,55 @@ +--- +title: Interagindo com o xahaud via Websocket e RPC +--- +O software xahaud fornece interfaces websocket e RPC que podem ser configuradas para uma variedade de casos de uso, como envio de transações ou consulta ao histórico do ledger. Alguns usuários podem optar por colocar software de proxy na frente do xahaud para fornecer criptografia, balanceamento de carga ou outros benefícios. É possível instalar certificados TLS no arquivo xahaud.cfg usando parâmetros como `ssl_key = [/caminho/para/chave]`. + +## Configurando Portas Websocket e RPC +Para habilitar portas de escuta, edite o arquivo `xahaud.cfg`. As portas habilitadas estão listadas na stanza `[server]` no arquivo de configuração. Cada porta listada na seção `[server]` deve ser definida adicionalmente por meio de sua própria stanza. Além de configurar portas websocket ou RPC, os administradores também podem configurar a porta usada para escutar conexões de peer de entrada (`port_peer`). Em servidores de validação, é ideal remover `port_peer` do arquivo de configuração, para evitar conexões de entrada. Um arquivo de configuração com o protocolo de peer, uma porta websocket e uma porta RPC pode ser assim:



+ +``` +[server] +port_peer +port_ws_public +port_rpc_public + +[port_peer] # Nome da porta. +protocol = peer # Campo obrigatório. +port = 21337 # Campo obrigatório. +ip = :: # Endereço da interface a vincular. + +[port_ws_public] +protocol = ws +port = 16006 +ip = :: +limit = 150 # Número máximo de clientes permitidos para se conectar a uma porta. "0" é ilimitado. +admin = [ 10.10.10.5, 10.11.11.0/24 ] # Endereços IP ou sub-redes permitidos para enviar requisições de [admin](/docs/features/http-websocket-apis/admin-api-methods). +secure_gateway = [ 10.10.10.20, 10.15.15.0/24 ] # Endereços permitidos para enviar cabeçalhos X-Forwarded-For e X-User. + +[port_rpc_public] +protocol = http +port = 16007 +ip = :: +``` +

+Opções adicionais de configuração para conexões websocket e RPC estão disponíveis no [Arquivo de Configuração de Exemplo](https://github.com/Xahau/xahaud/blob/dev/cfg/rippled-example.cfg). + +## RPC via UDP + +O xahaud suporta RPC baseado em UDP para consultas de alto desempenho e baixa latência. O RPC via UDP é útil para aplicações que precisam fazer muitas consultas rápidas e podem tolerar perda ocasional de pacotes. + +Para habilitar o RPC via UDP, adicione uma definição de porta UDP no seu `xahaud.cfg`: + +``` +[server] +port_udp_rpc + +[port_udp_rpc] +protocol = http +port = 16008 +ip = :: +transport = udp +``` + +As requisições RPC via UDP usam o mesmo formato JSON-RPC que o HTTP RPC, mas são enviadas como datagramas UDP. As respostas também são enviadas via UDP. Como o UDP não tem conexão, cada requisição deve incluir todo o contexto necessário, e os clientes devem lidar com possível perda de pacotes implementando lógica de nova tentativa. + +**Nota:** O RPC via UDP é mais adequado para operações somente leitura. O envio de transações deve usar WebSocket ou HTTP RPC para confiabilidade. diff --git a/src/content/docs/br/docs/infrastructure/system-requirements.mdx b/src/content/docs/br/docs/infrastructure/system-requirements.mdx new file mode 100644 index 0000000..eecbed4 --- /dev/null +++ b/src/content/docs/br/docs/infrastructure/system-requirements.mdx @@ -0,0 +1,24 @@ +--- +title: Requisitos de Sistema +--- +Os requisitos de hardware para nós personalizados para várias tarefas (ex.: RPC/WS, hubs, validadores, etc.) devem ser consistentes com as especificações descritas abaixo. Considere adaptar seu sistema individual com base no seu caso de uso pretendido. + +## Tipos de Nós +É possível executar o xahaud em diversas configurações, com base nas necessidades do usuário. Da mesma forma, um servidor xahaud pode ser configurado para múltiplos propósitos, como um servidor de histórico completo que também é usado para chamadas RPC/WS. O propósito do servidor determina os requisitos de sistema necessários. Algumas configurações do xahaud podem incluir: +1. Servidor padrão - Este termo é comumente usado para se referir a qualquer nó xahaud que não está configurado como validador. Um servidor padrão geralmente tem poucas alterações em relação à configuração padrão. +2. Servidores de histórico completo - São úteis para consultar dados históricos. Além de uma grande quantidade de espaço de armazenamento, potencialmente maiores IOPS de disco e largura de banda de rede são necessários, dependendo do número de usuários consultando o servidor. +3. Servidores RPC/Websocket - São adequados para tarefas como envio de transações ou consulta de dados atuais do ledger, como livros de ordens ou o fluxo de validação. O Nginx ou outro software de proxy é frequentemente colocado na frente de servidores RPC/WS para fornecer balanceamento de carga, criptografia e outros benefícios. +4. Servidor hub - O peering entre nós é crítico para retransmitir mensagens pela Rede Xahau, e um único servidor pode ser configurado para fornecer peering para centenas de pares. No entanto, uma grande quantidade de largura de banda pode ser necessária (10 Gbit+). +5. [Servidores de validação](/docs/infrastructure/enabling-validation) - Os validadores diferem de outros tipos de nós, pois requerem uma chave criptográfica adicional instalada, para que possam assinar a sequência de transações em um ledger proposto. Como disponibilidade e segurança são críticas, não é recomendado usar um validador para outras funções. + +## Notas Gerais +* As compilações são normalmente testadas no Ubuntu LTS. No entanto, Docker, binários portáteis, compilações personalizadas e outros métodos de instalação permitem suporte diversificado a sistemas operacionais. +* Normalmente, um endereço IPv4 e/ou IPv6 é necessário para cada instância do xahaud. Não é recomendado executar múltiplas instâncias por trás de um único endereço IPv4. +* Máquinas que armazenam histórico completo devem usar XFS ou similar para evitar limitações com tamanho de arquivo único no EXT4 (tamanho máximo de arquivo de 16TB). Se armazenar menos histórico, o EXT4 é suficiente. +* Pode ser possível executar o xahaud em máquinas que não atendem às especificações "Mínimas" abaixo para servidores de produção. No entanto, fazer isso arrisca instabilidade. +* Esses requisitos de sistema podem crescer com o tempo. Por exemplo, o espaço em disco para servidores de histórico completo está consistentemente aumentando. +* A partir de 1º de novembro de 2025, o histórico completo da Rede Xahau é de 10TB. + +## Especificações Recomendadas para Servidores xahaud de Produção + +
MínimoPreferidoIdeal
CPU (2.5+ GHz x86_64)8 núcleos20 núcleos40+ núcleos
Memória32GB64GB128GB+
Disco IO (sustentado)15k RW aleatório20k RW aleatório30k RW aleatório
Tamanho do Disco500GB1TB20TB+
Sistema de ArquivosXFSXFSXFS
Rede IO500Mbit+1Gbit10Gbit
diff --git a/src/content/docs/br/docs/infrastructure/updating-xahaud.mdx b/src/content/docs/br/docs/infrastructure/updating-xahaud.mdx new file mode 100644 index 0000000..233e334 --- /dev/null +++ b/src/content/docs/br/docs/infrastructure/updating-xahaud.mdx @@ -0,0 +1,49 @@ +--- +title: Atualizar o xahaud +--- +O processo de atualização do xahaud varia dependendo do método de instalação usado; porém, todos os três métodos dependem das versões publicadas em [https://build.xahau.tech](https://build.xahau.tech). Ao atualizar um validador, hub ou outra infraestrutura 'crítica', verifique a saúde da rede antes de reiniciar um servidor para instalar uma atualização. É possível automatizar o processo de atualização usando uma entrada de crontab e um script de atualização; no entanto, os administradores são desencorajados a fazê-lo, pois atualizações automáticas podem resultar em reinicializações em momentos em que a rede está instável. Da mesma forma, a presença humana permite que os operadores garantam que as atualizações sejam bem-sucedidas, minimizando o tempo de inatividade. + +## Backup +Os usuários devem sempre manter backups de: +1. O arquivo de configuração principal: `xahaud.cfg` + - A localização varia com base no tipo de instalação. +2. O arquivo de validadores confiáveis: `validators-xahau.txt` + - A localização é especificada em 'xahaud.cfg'. +3. As credenciais de identidade do servidor: `wallet.db` + - Localizado no diretório de banco de dados definido em 'xahaud.cfg'. +4. Os validadores devem manter sua chave privada de validação com backup em um local seguro e offline. + +## Atualizando Contêineres Docker +Atualizar o xahaud dentro de um contêiner Docker envolve substituir o binário em execução pela nova versão, baixada de [https://build.xahau.tech](https://build.xahau.tech). Isso pode ser feito substituindo o binário do xahaud dentro do contêiner ou atualizando o contêiner inteiro. +

+Para atualizar o binário do xahaud dentro de um contêiner Docker em execução: +1. Baixe o [script](https://gist.githubusercontent.com/WietseWind/2ed35d85dcd056d82645de2958934f86/raw/34be773fd6af42e82cc3a21baf70bfb1e2a6c583/update.sh): `wget https://gist.githubusercontent.com/WietseWind/2ed35d85dcd056d82645de2958934f86/raw/34be773fd6af42e82cc3a21baf70bfb1e2a6c583/update.sh` +2. Edite o script e altere a primeira linha para a [versão de lançamento](https://build.xahau.tech) que deseja instalar. +3. Execute o script: `bash ./update.sh` +4. Verifique se o xahaud está em execução: `docker exec xahaud-[mainnet/testnet] xahaud server_info` +

+Para substituir a imagem Docker atual por uma nova versão, sem sobrescrever bancos de dados ou arquivos de configuração (que são ignorados pelo arquivo .gitignore): +1. Navegue até o repositório: `cd [/caminho/para/docker-repo]` +2. Atualize para a versão mais recente: `git pull` +3. Liste os contêineres Docker em execução e anote o nome do contêiner xahaud: `docker ps` +4. Pare a instância antiga do xahaud: `docker stop xahaud-[mainnet/testnet]` +5. Remova a instância antiga: `docker rm xahaud-[mainnet/testnet]` +6. Inicie a nova instância: `./build && ./up` + +## Atualizando Instalações Locais +Para atualizar uma versão instalada localmente do xahaud, basta substituir o binário atual por um novo: +1. Baixe o novo binário de: [https://build.xahau.tech](https://build.xahau.tech) +2. Marque o novo binário como executável: `chmod +x [/caminho/para/download]` +3. Pare a instância do xahaud em execução: `/opt/xahaud/bin/xahaud stop` +4. Substitua o binário antigo pelo novo: `mv [/caminho/para/download] /opt/xahaud/bin/xahaud` +5. Inicie o xahaud: `systemctl start xahaud` +6. Verifique se o xahaud está em execução: `/opt/xahaud/bin/xahaud server_info` +

+Um [script](https://gist.githubusercontent.com/WietseWind/9480a4fc95e904e54524406005c8c963/raw/2b200fdc2e5b471ae4f6625674aff1765d63e744/update.sh) que automatiza os passos acima está disponível. + +## Atualizando Arquivos Binários +Atualizar os arquivos binários do xahaud é essencialmente o mesmo que as instruções de instalação originais: +1. Remova a versão em execução: `rm [/caminho/para/xahaud]` +2. Baixe a nova versão: [https://build.xahau.tech](https://build.xahau.tech) +3. Marque o download como executável: `chmod 500 [/caminho/para/xahaud]` +4. Inicie o xahaud: `./[caminho/para/xahaud] --net --conf [/caminho/para/xahaud.cfg]` diff --git a/src/content/docs/br/docs/protocol-reference/binary-format.mdx b/src/content/docs/br/docs/protocol-reference/binary-format.mdx new file mode 100644 index 0000000..e9c9830 --- /dev/null +++ b/src/content/docs/br/docs/protocol-reference/binary-format.mdx @@ -0,0 +1,302 @@ +--- +title: Formato Binário +--- +[\[Fonte\]](https://github.com/Xahau/xahaud/blob/dev/src/ripple/protocol/impl/STObject.cpp#L696-L718) + +Esta página descreve o formato binário canônico do Xahau para transações e outros dados. Esse formato binário é necessário para criar e verificar assinaturas digitais do conteúdo das transações, e também é usado em outros contextos, incluindo as comunicações peer-to-peer entre servidores. As APIs do `xahaud` tipicamente usam JSON para comunicação com aplicações clientes. Porém, o JSON é inadequado como formato para serializar transações a serem assinadas digitalmente, pois pode representar os mesmos dados de diversas formas equivalentes diferentes. + +O processo de serialização de uma transação do JSON (ou qualquer outra representação) para seu formato binário canônico pode ser resumido nas seguintes etapas: + +1. Certifique-se de que todos os campos obrigatórios estejam presentes, incluindo os campos obrigatórios "auto-preenchíveis". + + A Referência de Formatos de Transação define os campos obrigatórios e opcionais para transações Xahau. + + **Nota:** O `SigningPubKey` também deve ser fornecido nesta etapa. Ao assinar, você pode derivar esta chave a partir da chave secreta usada na assinatura. +2. Converta os dados de cada campo para seu formato binário "interno". +3. Ordene os campos em ordem canônica. +4. Prefixe cada campo com um Field ID. +5. Concatene os campos (incluindo prefixos) na ordem classificada. + +O resultado é um único blob binário que pode ser assinado usando algoritmos de assinatura bem conhecidos, como ECDSA (com a curva elíptica secp256k1) e Ed25519. Para fins do Xahau, você também deve fazer o \[hash]\[Hash] dos dados com o prefixo apropriado (`0x53545800` para assinatura simples, ou `0x534D5400` para multi-assinatura). Após assinar, você deve re-serializar a transação com o campo `TxnSignature` incluído. + +**Nota:** O Xahau usa o mesmo formato de serialização para representar outros tipos de dados, como objetos de ledger e transações processadas. Porém, apenas determinados campos são adequados para inclusão em uma transação a ser assinada. (Por exemplo, o campo `TxnSignature`, que contém a própria assinatura, não deve estar presente no blob binário que você assina.) Assim, alguns campos são designados como "Signing" (incluídos quando os objetos são assinados) e "non-signing" (não incluídos nos dados a serem assinados). + +#### Exemplos + +Tanto transações assinadas quanto não assinadas podem ser representadas em formato JSON e binário. Os exemplos a seguir mostram a mesma transação assinada nos dois formatos: + +**JSON:** + +```json + +
+ +``` + +**Binário (representado em hexadecimal):** + +``` + +
+ +``` + +### Código de Exemplo + +Os processos de serialização descritos aqui estão implementados em vários lugares e linguagens de programação: + +* Em C++ [na base de código do `rippled`](https://github.com/Xahau/xahaud/blob/dev/src/ripple/protocol/impl/STObject.cpp). +* Em JavaScript na seção de exemplos de código deste repositório. +* Em Python 3 na seção de exemplos de código deste repositório. + +Além disso, muitas bibliotecas clientes fornecem suporte à serialização sob licenças de código aberto permissivas, para que você possa importar, usar ou adaptar o código conforme suas necessidades. + +### Formato Interno + +Cada campo tem um formato binário "interno" usado no código-fonte do `xahaud` para representar esse campo ao assinar (e na maioria dos outros casos). Os formatos internos de todos os campos são definidos no código-fonte de [`SField.cpp`](https://github.com/Xahau/xahaud/blob/master/src/ripple/protocol/impl/SField.cpp). (Este arquivo também inclui campos além dos campos de transação.) A Referência de Formato de Transação também lista os formatos internos para todos os campos de transação. + +Por exemplo, o campo comum de transação `Flags` se torna um UInt32 (inteiro sem sinal de 32 bits). + +#### Arquivo de Definições + +O seguinte arquivo JSON define as constantes importantes necessárias para serializar dados do Xahau para o formato binário e desserializá-los do binário: + +[**https://github.com/Xahau/xahau.js/tree/main-xahau/packages/xahau-binary-codec/src/enums/definitions.json**](https://github.com/Xahau/xahau.js/tree/main-xahau/packages/xahau-binary-codec/src/enums/definitions.json) + +A tabela a seguir define os campos de nível superior do arquivo de definições: + +| Campo | Conteúdo | +| --------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `TYPES` | Mapa de tipos de dados para seus "códigos de tipo" usados na construção de IDs de campo e na ordenação de campos em ordem canônica. Códigos abaixo de 1 não devem aparecer em dados reais; códigos acima de 10000 representam tipos "de alto nível" especiais, como "Transaction", que não podem ser serializados dentro de outros objetos. Consulte a Lista de Tipos para detalhes sobre como serializar cada tipo. | +| `LEDGER_ENTRY_TYPES` | Mapa de objetos de ledger para seu tipo de dados. Aparecem nos dados de estado do ledger e na seção de "nós afetados" dos metadados de transações processadas. | +| `FIELDS` | Um array ordenado de tuplas representando todos os campos que podem aparecer em transações, objetos de ledger ou outros dados. O primeiro membro de cada tupla é o nome do campo em string e o segundo é um objeto com as propriedades desse campo. (Consulte a tabela "Propriedades de campo" abaixo para definições desses campos.) | +| `TRANSACTION_RESULTS` | Mapa de códigos de resultado de transação para seus valores numéricos. Tipos de resultado não incluídos nos ledgers têm valores negativos; `tesSUCCESS` tem valor numérico 0; códigos da classe `tec` representam falhas incluídas nos ledgers. | +| `TRANSACTION_TYPES` | Mapa de todos os tipos de transação para seus valores numéricos. | + +Para fins de serialização de transações para assinatura e envio, os campos `FIELDS`, `TYPES` e `TRANSACTION_TYPES` são necessários. + +Os objetos de definição de campo no array `FIELDS` têm os seguintes campos: + +| Campo | Tipo | Conteúdo | +| ---------------- | ------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `nth` | Number | O código de campo deste campo, usado na construção do seu Field ID e na ordenação junto a outros campos do mesmo tipo de dado. | +| `isVLEncoded` | Boolean | Se `true`, este campo tem prefixo de comprimento. | +| `isSerialized` | Boolean | Se `true`, este campo deve ser codificado em dados binários serializados. Quando `false`, o campo é tipicamente reconstruído sob demanda em vez de armazenado. | +| `isSigningField` | Boolean | Se `true`, este campo deve ser serializado ao preparar uma transação para assinatura. Se `false`, este campo deve ser omitido dos dados a serem assinados. (Pode não fazer parte das transações.) | +| `type` | String | O tipo de dado interno deste campo. Mapeia para uma chave no mapa `TYPES`, que fornece o código de tipo do campo. | + +#### IDs de Campo + +[\[Fonte - Codificação\]](https://github.com/seelabs/rippled/blob/cecc0ad75849a1d50cc573188ad301ca65519a5b/src/ripple/protocol/impl/Serializer.cpp#L117-L148) [\[Fonte - Decodificação\]](https://github.com/seelabs/rippled/blob/cecc0ad75849a1d50cc573188ad301ca65519a5b/src/ripple/protocol/impl/Serializer.cpp#L484-L509) + +Ao combinar o código de tipo e o código de campo, obtém-se o identificador único do campo, que é prefixado antes do campo no blob serializado final. O tamanho do Field ID é de um a três bytes, dependendo dos códigos de tipo e campo que combina. Veja a tabela abaixo: + +| | Código de Tipo < 16 | Código de Tipo >= 16 | +| -------------------- | -------------- | --------------- | +| **Código de Campo < 16** | | | +| **Código de Campo >= 16** | | | + +Ao decodificar, você pode saber quantos bytes tem o Field ID verificando quais bits **do primeiro byte** são zeros. Isso corresponde aos casos na tabela acima: + +| | 4 bits superiores não são zero | 4 bits superiores são zero | +| -------------------------- | --------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------- | +| **4 bits inferiores não são zero** | 1 byte: os 4 bits superiores definem o tipo; os 4 bits inferiores definem o campo. | 2 bytes: os 4 bits inferiores do primeiro byte definem o campo; o próximo byte define o tipo | +| **4 bits inferiores são zero** | 2 bytes: os 4 bits superiores do primeiro byte definem o tipo; os 4 bits inferiores do primeiro byte são 0; o próximo byte define o campo | 3 bytes: o primeiro byte é `0x00`, o segundo byte define o tipo; o terceiro byte define o campo | + +**Atenção:** Embora o Field ID seja composto pelos dois elementos usados para ordenar campos, você não deve ordenar pelo Field ID serializado em si, pois a estrutura de bytes do Field ID altera a ordem de classificação. + +#### Prefixação de Comprimento + +Alguns tipos de campos de comprimento variável são prefixados com um indicador de comprimento. Campos do tipo `Blob` (contendo dados binários arbitrários) são um exemplo desse tipo. Para saber quais tipos têm prefixo de comprimento, consulte a tabela Lista de Tipos. + +**Nota:** Alguns tipos de campos de comprimento variável não têm prefixo de comprimento. Esses tipos têm outras formas de indicar o fim de seu conteúdo. + +O prefixo de comprimento consiste em um a três bytes indicando o comprimento do campo imediatamente após o prefixo de tipo e antes do conteúdo. + +* Se o campo contém de 0 a 192 bytes de dados, o primeiro byte define o comprimento do conteúdo; em seguida, esse número de bytes de dados segue imediatamente após o byte de comprimento. +* Se o campo contém de 193 a 12480 bytes de dados, os primeiros dois bytes indicam o comprimento do campo com a seguinte fórmula: + + ``` + 193 + ((byte1 - 193) * 256) + byte2 + ``` +* Se o campo contém de 12481 a 918744 bytes de dados, os primeiros três bytes indicam o comprimento do campo com a seguinte fórmula: + + ``` + 12481 + ((byte1 - 241) * 65536) + (byte2 * 256) + byte3 + ``` +* Um campo com prefixo de comprimento não pode conter mais de 918744 bytes de dados. + +Ao decodificar, você pode saber pelo valor do primeiro byte de comprimento se há 0, 1 ou 2 bytes de comprimento adicionais: + +* Se o primeiro byte de comprimento tem valor de 192 ou menos, é o único byte de comprimento e contém o tamanho exato do conteúdo do campo em bytes. +* Se o primeiro byte de comprimento tem valor de 193 a 240, há dois bytes de comprimento. +* Se o primeiro byte de comprimento tem valor de 241 a 254, há três bytes de comprimento. + +### Ordem Canônica de Campos + +Todos os campos em uma transação são ordenados em uma ordem específica baseada primeiro no tipo do campo (especificamente, um "código de tipo" numérico atribuído a cada tipo) e depois no próprio campo (um "código de campo"). (Pense como uma ordenação por sobrenome e depois por nome, onde o sobrenome é o tipo do campo e o nome é o próprio campo.) + +#### Códigos de Tipo + +Cada tipo de campo tem um código de tipo arbitrário, com códigos menores sendo classificados primeiro. Esses códigos são definidos em [`SField.h`](https://github.com/Xahau/xahaud/blob/master/src/ripple/protocol/SField.h#L57-L74). + +Por exemplo, [UInt32 tem código de tipo 2](https://github.com/Xahau/xahaud/blob/72e6005f562a8f0818bc94803d222ac9345e1e40/src/ripple/protocol/SField.h#L59), então todos os campos UInt32 vêm antes de todos os [campos Amount, que têm código de tipo 6](https://github.com/Xahau/xahaud/blob/72e6005f562a8f0818bc94803d222ac9345e1e40/src/ripple/protocol/SField.h#L63). + +O arquivo de definições lista os códigos de tipo para cada tipo no mapa `TYPES`. + +#### Códigos de Campo + +Cada campo tem um código de campo, usado para ordenar campos do mesmo tipo, com códigos menores sendo classificados primeiro. Esses campos são definidos em [`SField.cpp`](https://github.com/Xahau/xahaud/blob/72e6005f562a8f0818bc94803d222ac9345e1e40/src/ripple/protocol/impl/SField.cpp#L72-L266). + +Por exemplo, o campo `Account` de uma \[transação Payment]\[] [tem código de ordenação 1](https://github.com/Xahau/xahaud/blob/72e6005f562a8f0818bc94803d222ac9345e1e40/src/ripple/protocol/impl/SField.cpp#L219), portanto vem antes do campo `Destination`, que [tem código de ordenação 3](https://github.com/Xahau/xahaud/blob/72e6005f562a8f0818bc94803d222ac9345e1e40/src/ripple/protocol/impl/SField.cpp#L221). + +Os códigos de campo são reutilizados para campos de diferentes tipos, mas campos do mesmo tipo nunca têm o mesmo código de campo. Ao combinar o código de tipo com o código de campo, obtém-se o Field ID único do campo. + +### Lista de Tipos + +As instruções de transação podem conter campos de qualquer um dos seguintes tipos: + +| Nome do Tipo | Código de Tipo | Comprimento em Bits | Com Prefixo de Comprimento? | Descrição | +| ------------ | -------------- | ------------------- | --------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| AccountID | 8 | 160 | Sim | O identificador único de uma conta. | +| Amount | 6 | 64 ou 384 | Não | Um valor em XAH ou tokens. O comprimento é de 64 bits para XAH ou 384 bits (64+160+160) para tokens. | +| Blob | 7 | Variável | Sim | Dados binários arbitrários. Um campo importante desse tipo é `TxnSignature`, a assinatura que autoriza uma transação. | +| Hash128 | 4 | 128 | Não | Um valor binário arbitrário de 128 bits. O único campo desse tipo é `EmailHash`, destinado a armazenar o hash MD-5 do e-mail do proprietário de uma conta para busca de [Gravatar](https://www.gravatar.com/). | +| Hash160 | 17 | 160 | Não | Um valor binário arbitrário de 160 bits. Pode definir um código de moeda ou emissor. | +| Hash256 | 5 | 256 | Não | Um valor binário arbitrário de 256 bits. Normalmente representa o hash "SHA-512Half" de uma transação, versão de ledger ou objeto de dados de ledger. | +| PathSet | 18 | Variável | Não | Um conjunto de possíveis caminhos de pagamento para um pagamento entre moedas diferentes. | +| STArray | 15 | Variável | Não | Um array contendo um número variável de membros, que podem ser de tipos diferentes dependendo do campo. Dois exemplos incluem memos e listas de signatários usadas em multi-assinatura. | +| STIssue | 24 | 160 ou 320 | Não | Uma definição de ativo, XAH ou token, sem quantidade. | +| STObject | 14 | Variável | Não | Um objeto contendo um ou mais campos aninhados. | +| UInt8 | 16 | 8 | Não | Um inteiro sem sinal de 8 bits. | +| UInt16 | 1 | 16 | Não | Um inteiro sem sinal de 16 bits. O `TransactionType` é um caso especial deste tipo, com strings específicas mapeando para valores inteiros. | +| UInt32 | 2 | 32 | Não | Um inteiro sem sinal de 32 bits. Os campos `Flags` e `Sequence` em todas as transações são exemplos desse tipo. | + +Além de todos os tipos de campo acima, os seguintes tipos podem aparecer em outros contextos, como objetos de ledger e metadados de transação: + +| Nome do Tipo | Código de Tipo | Com Prefixo de Comprimento? | Descrição | +| ------------ | -------------- | --------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Transaction | 10001 | Não | Um tipo "de alto nível" contendo uma transação completa. | +| LedgerEntry | 10002 | Não | Um tipo "de alto nível" contendo um objeto de ledger completo. | +| Validation | 10003 | Não | Um tipo "de alto nível" usado em comunicações peer-to-peer para representar um voto de validação no processo de consenso. | +| Metadata | 10004 | Não | Um tipo "de alto nível" contendo metadados de uma transação. | +| UInt64 | 3 | Não | Um inteiro sem sinal de 64 bits. Este tipo não aparece em instruções de transação, mas vários objetos de ledger usam campos deste tipo. | +| Vector256 | 19 | Sim | Este tipo não aparece em instruções de transação, mas o campo `Amendments` do objeto de ledger Amendments usa este tipo para representar quais emendas estão habilitadas. | + +#### Campos AccountID + +Campos deste tipo contêm o identificador de 160 bits de uma conta do XRP Ledger. Em JSON, esses campos são representados como endereços \[base58]\[] do XRP Ledger, com dados de checksum adicionais para que erros de digitação dificilmente resultem em endereços válidos. (Essa codificação, às vezes chamada de "Base58Check", evita o envio acidental de dinheiro para o endereço errado.) O formato binário para esses campos não contém dados de checksum nem o prefixo de tipo `0x00` usado na codificação base58 de endereços. (Porém, como o formato binário é usado principalmente para transações assinadas, um erro de digitação ou transcrição em uma transação assinada invalidaria a assinatura, impedindo o envio.) + +AccountIDs que aparecem como campos independentes (como `Account` e `Destination`) têm prefixo de comprimento apesar de terem exatamente 160 bits. Como resultado, o indicador de comprimento para esses campos é sempre o byte `0x14`. AccountIDs que aparecem como filhos de campos especiais (campo `issuer` de Amount e `account` de PathSet) _não_ têm prefixo de comprimento. + +#### Campos Amount + +O tipo "Amount" é um tipo especial de campo que representa um valor de moeda, seja XAH ou um token. Este tipo consiste em dois subtipos: + +* XAH + + O XAH é serializado como um inteiro sem sinal de 64 bits (ordem big-endian), exceto que o bit mais significativo é sempre 0 para indicar que é XAH, e o segundo bit mais significativo é `1` para indicar que é positivo. Como o valor máximo de XAH (10¹⁷ drops) requer apenas 57 bits, você pode calcular o formato serializado de XAH pegando um inteiro sem sinal padrão de 64 bits e realizando uma operação bitwise-OR com `0x4000000000000000`. +* **Tokens** + + Tokens consistem em três segmentos em ordem: + + 1. 64 bits indicando o valor no formato de valor de token. O primeiro bit é `1` para indicar que não é XAH. + 2. 160 bits indicando o código de moeda. A API padrão converte códigos de 3 caracteres como "USD" em códigos de 160 bits usando o formato padrão de código de moeda, mas códigos personalizados de 160 bits também são possíveis. + 3. 160 bits indicando o AccountID do emissor. (Veja também: Codificação de Endereço de Conta) + +Você pode identificar qual dos dois subtipos é pelo primeiro bit: `0` para XAH; `1` para tokens. + +**Formato de Valor de Token** + +[\[Fonte\]](https://github.com/Xahau/xahaud/blob/35fa20a110e3d43ffc1e9e664fc9017b6f2747ae/src/ripple/protocol/impl/STAmount.cpp) + +O Xahau usa 64 bits para serializar o valor numérico de um token (fungível). (No formato JSON, o valor numérico é o campo `value` de um objeto de valor em moeda.) No formato binário, o valor numérico consiste em um bit "not XAH", um bit de sinal, dígitos significativos e um expoente, nesta ordem: + +1. O primeiro bit (mais significativo) de um valor de token é `1` para indicar que não é um valor XAH. (Valores XAH sempre têm o bit mais significativo definido como `0` para distingui-los deste formato.) +2. O bit de sinal indica se o valor é positivo ou negativo. Ao contrário dos inteiros padrão em [complemento de dois](https://en.wikipedia.org/wiki/Two's_complement), `1` indica **positivo** no formato Xahau, e `0` indica negativo. +3. Os próximos 8 bits representam o expoente como um inteiro sem sinal. O expoente indica a escala (a que potência de 10 os dígitos significativos devem ser multiplicados) no intervalo de -96 a +80 (inclusivo). Porém, ao serializar, adicionamos 97 ao expoente para permitir a serialização como inteiro sem sinal. Assim, um valor serializado de `1` indica expoente `-96`, um valor serializado de `177` indica expoente 80, e assim por diante. +4. Os 54 bits restantes representam os dígitos significativos (às vezes chamados de _mantissa_) como um inteiro sem sinal. Ao serializar, esse valor é normalizado para o intervalo de 10¹⁵ (`1000000000000000`) a 10¹⁶-1 (`9999999999999999`) inclusive, exceto no caso especial do valor 0. No caso especial de 0, o bit de sinal, o expoente e os dígitos significativos são todos zeros, portanto o valor de 64 bits é serializado como `0x8000000000000000000000000000000000000000`. + +O valor numérico é serializado junto com o código de moeda e o emissor para formar um valor de token completo. + +**Códigos de Moeda** + +No nível de protocolo, os códigos de moeda no Xahau são valores arbitrários de 160 bits, exceto pelos seguintes valores que têm significado especial: + +* O código de moeda `0x0000000000000000000000005852500000000000` é **sempre proibido**. (Este é o código "XAH" no "formato padrão".) +* O código de moeda `0x0000000000000000000000000000000000000000` (todos zeros) é **geralmente proibido**. Normalmente, valores XAH não são especificados com códigos de moeda. Porém, este código é usado para indicar XAH em casos raros em que um campo deve especificar um código de moeda para XAH. + +As APIs do `xahaud` suportam um **formato padrão** para traduzir códigos ASCII de três caracteres para valores hexadecimais de 160 bits da seguinte forma: + +1. Os primeiros 8 bits devem ser `0x00`. +2. Os próximos 88 bits são reservados e devem ser todos `0`. +3. Os próximos 24 bits representam 3 caracteres ASCII. Recomenda-se usar códigos [ISO 4217](https://www.xe.com/iso4217.php) ou pseudo-ISO 4217 populares como "BTC". Porém, qualquer combinação dos seguintes caracteres é permitida: todas as letras maiúsculas e minúsculas, dígitos e os símbolos `?`, `!`, `@`, `#`, `$`, `%`, `^`, `&`, `*`, `<`, `>`, `(`, `)`, `{`, `}`, `[`, `]` e `|`. O código de moeda XAH (todo maiúsculo) é reservado para XAH e não pode ser usado por tokens. +4. Os próximos 40 bits são reservados e devem ser todos `0`. + +O **formato não padrão** é qualquer dado de 160 bits desde que os primeiros 8 bits não sejam `0x00`. + +#### Campos Array + +Alguns campos de transação, como `SignerEntries` (em \[transações SignerListSet]\[]) e `Memos`, são arrays de objetos (chamados de tipo "STArray"). + +Arrays contêm vários campos de objeto em seu formato binário nativo em uma ordem específica. Em JSON, cada membro do array é um objeto JSON "wrapper" com um único campo, que é o nome do campo do objeto membro. O valor desse campo é o próprio objeto ("interno"). + +No formato binário, cada membro do array tem um prefixo de Field ID (baseado na única chave do objeto wrapper) e conteúdo (composto pelo objeto interno serializado como objeto). Para marcar o fim de um array, adicione um item com um "Field ID" de `0xf1` (o código de tipo para array com código de campo 1) e sem conteúdo. + +#### Campos Blob + +O tipo Blob é um campo com prefixo de comprimento e dados arbitrários. Dois campos comuns que usam esse tipo são `SigningPubKey` e `TxnSignature`, que contêm (respectivamente) a chave pública e a assinatura que autorizam a execução de uma transação. + +Campos Blob não têm mais estrutura em seu conteúdo, portanto consistem exatamente na quantidade de bytes indicada na codificação de comprimento variável, após o Field ID e os prefixos de comprimento. + +#### Campos Hash + +O Xahau tem vários tipos "hash": Hash128, Hash160 e Hash256. Esses campos contêm dados binários arbitrários do número especificado de bits, que podem ou não representar o resultado de uma operação de hash. + +Todos esses campos são serializados com o número específico de bits, sem indicador de comprimento, na ordem big-endian de bytes. + +#### Campos Issue + +Alguns campos especificam um _tipo_ de ativo, que pode ser XAH ou um token fungível, sem quantidade. Esses campos consistem em um ou dois segmentos de 160 bits em ordem: + +1. Os primeiros 160 bits são o código de moeda do ativo. Para XAH, são todos 0. +2. Se os primeiros 160 bits forem todos 0 (o ativo é XAH), o campo termina aí. Caso contrário, o ativo é um token e os próximos 160 bits são o AccountID do emissor do token. + +#### Campos Object + +Alguns campos, como `SignerEntry` (em \[transações SignerListSet]\[]) e `Memo` (em arrays `Memos`), são objetos (chamados de tipo "STObject"). A serialização de objetos é muito similar à de arrays, com uma diferença: **os membros do objeto devem ser colocados em ordem canônica** dentro do campo objeto, enquanto campos de array já têm uma ordem explícita. + +A ordem canônica de campos de objetos é a mesma que a ordem canônica de todos os campos de nível superior, mas os membros do objeto devem ser ordenados dentro do objeto. Após o último membro, há um Field ID de "fim de objeto" de `0xe1` sem conteúdo. + +#### Campos PathSet + +O campo `Paths` de uma \[transação Payment]\[] entre moedas é um "PathSet", representado em JSON como um array de arrays. Para mais informações sobre o uso de caminhos, consulte Paths. + +Um PathSet é serializado como **1 a 6** caminhos individuais em sequência[\[Fonte\]](https://github.com/Xahau/xahaud/blob/4cff94f7a4a05302bdf1a248515379da99c5bcd4/src/ripple/app/tx/impl/Payment.h#L35-L36). Cada caminho completo é seguido por um byte que indica o que vem a seguir: + +* `0xff` indica que outro caminho segue +* `0x00` indica o fim do PathSet + +Cada caminho consiste em **1 a 8** etapas de caminho em ordem[\[Fonte\]](https://github.com/Xahau/xahaud/blob/4cff94f7a4a05302bdf1a248515379da99c5bcd4/src/ripple/app/tx/impl/Payment.h#L38-L39). Cada etapa começa com um byte de **tipo**, seguido por um ou mais campos descrevendo a etapa do caminho. O tipo indica quais campos estão presentes naquela etapa do caminho por meio de flags bitwise. (Por exemplo, o valor `0x30` indica mudança tanto de moeda quanto de emissor.) Se mais de um campo estiver presente, os campos são sempre colocados em uma ordem específica. + +A tabela a seguir descreve os possíveis campos e os flags bitwise a definir no byte de tipo para indicá-los: + +| Flag de Tipo | Campo Presente | Tipo de Campo | Tamanho em Bits | Ordem | +| ------------ | -------------- | --------------- | --------------- | ----- | +| `0x01` | `account` | AccountID | 160 bits | 1º | +| `0x10` | `currency` | Código de Moeda | 160 bits | 2º | +| `0x20` | `issuer` | AccountID | 160 bits | 3º | + +Algumas combinações são inválidas; consulte Especificações de Caminho para detalhes. + +Os AccountIDs nos campos `account` e `issuer` são apresentados _sem_ prefixo de comprimento. Quando a `currency` é XRP, o código de moeda é representado como 160 bits de zeros. + +Cada etapa é seguida diretamente pela próxima etapa do caminho. Como descrito acima, a última etapa de um caminho é seguida por `0xff` (se outro caminho segue) ou `0x00` (se este encerra o último caminho). + +#### Campos UInt + +O Xahau tem vários tipos de inteiro sem sinal: UInt8, UInt16, UInt32 e UInt64. Todos são inteiros sem sinal binários big-endian padrão com o número especificado de bits. + +Ao representar esses campos em objetos JSON, a maioria é representada como números JSON por padrão. Uma exceção é UInt64, que é representado como uma string porque alguns decodificadores JSON podem tentar representar esses inteiros como números de ponto flutuante de "precisão dupla" de 64 bits, que não podem representar todos os valores UInt64 distintos com precisão total. + +Outro caso especial é o campo `TransactionType`. Em JSON, este campo é convencionalmente representado como uma string com o nome do tipo de transação, mas em binário é um UInt16. O objeto `TRANSACTION_TYPES` no arquivo de definições mapeia essas strings para valores numéricos específicos. diff --git a/src/content/docs/br/docs/protocol-reference/data-types/base-58-encodings.mdx b/src/content/docs/br/docs/protocol-reference/data-types/base-58-encodings.mdx new file mode 100644 index 0000000..4820a17 --- /dev/null +++ b/src/content/docs/br/docs/protocol-reference/data-types/base-58-encodings.mdx @@ -0,0 +1,24 @@ +--- +title: Codificações Base 58 +--- +As APIs do Xahau frequentemente usam uma codificação "base58" com checksum (às vezes chamada de "Base58Check") para representar endereços de conta e outros tipos de valores relacionados a chaves criptográficas. Essa codificação é a mesma que [a usada para endereços Bitcoin](https://en.bitcoin.it/wiki/Base58Check_encoding), exceto que o Xahau usa o seguinte dicionário: `rpshnaf39wBUDNEGHJKLM4PQRST7VWXYZ2bcdeCg65jkm8oFqi1tuvAxyz`. + +O Xahau prefixa diferentes tipos de valores com um número específico de 8 bits antes de codificá-los para distinguir entre diferentes tipos de dados. Com o arranjo de caracteres no dicionário base58 do Xahau, o resultado é que as representações base58 para diferentes tipos de valores codificados começam com letras específicas por tipo. + +A tabela a seguir lista todas as codificações que o Xahau usa: + +| Tipo de Dado | Começa Com | Prefixo de Tipo | Tamanho do Conteúdo¹ | Máximo de Caracteres | +| ----------------------------------------------- | ---------- | --------------- | -------------------- | -------------------- | +| Endereço de conta | r | `0x00` | 20 bytes | 35 | +| Chave pública de conta | a | `0x23` | 33 bytes | 53 | +| Valor de semente (para chaves secretas) | s | `0x21` | 16 bytes | 29 | +| Chave pública de validação ou chave pública de nó | n | `0x1C` | 33 bytes | 53 | + +¹ O tamanho do conteúdo exclui o prefixo de tipo de 1 byte. + +### Veja Também + +* Codificação de Endereços - informações detalhadas sobre codificação de endereços +* Chaves Criptográficas - tipos de chaves criptográficas no Xahau e como são usadas +* \[Referência wallet_propose]\[método wallet_propose] - método de API para gerar chaves de conta +* \[Referência validation_create]\[método validation_create] - método de API para gerar chaves de validador diff --git a/src/content/docs/br/docs/protocol-reference/data-types/currency-formats.mdx b/src/content/docs/br/docs/protocol-reference/data-types/currency-formats.mdx new file mode 100644 index 0000000..c17c673 --- /dev/null +++ b/src/content/docs/br/docs/protocol-reference/data-types/currency-formats.mdx @@ -0,0 +1,117 @@ +--- +title: Formatos de Moeda +--- +O Xahau tem dois tipos de ativos digitais: XAH e tokens. Ambos os tipos têm alta precisão, embora seus formatos sejam diferentes. + +### Comparação + +A tabela a seguir resume algumas das diferenças entre XAH e tokens no Xahau: + +| XAH | Tokens | +| -------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------- | +| Não tem emissor. | Sempre emitido por uma conta Xahau. | +| Especificado como uma string. | Especificado como um objeto. | +| Rastreado em contas. | Rastreado em linhas de confiança. | +| Nunca pode ser criado; só pode ser destruído. | Pode ser emitido ou resgatado livremente. | +| Valor mínimo: `0`. (Não pode ser negativo.) | Valor mínimo: `-9999999999999999e80`. Valor absoluto mínimo diferente de zero: `1000000000000000e-96`. | +| Valor máximo `100000000000` (10¹¹) XAH. Isso equivale a `100000000000000000` (10¹⁷) "drops". | Valor máximo `9999999999999999e80`. | +| Preciso ao "drop" mais próximo (0,000001 XAH) | 15 dígitos decimais de precisão. | +| Não pode ser congelado. | O emissor pode congelar saldos. | +| Sem taxas de transferência; pagamentos XAH-para-XAH são sempre diretos. | Pode percorrer caminhos indiretos com cada emissor cobrando uma taxa de transferência percentual. | +| Pode ser usado em Canais de Pagamento e Escrow. | Pode ser usado com Canais de Pagamento ou Escrow. | + +Para mais informações, consulte O que é XAH? e Tokens. + +### Especificando Valores em Moeda + +Use o formato apropriado para o tipo de moeda que deseja especificar: + +* Valores em XAH +* Valores em Tokens + +#### Valores em XAH + +Para especificar um valor de XAH, use um Número String indicando _drops_ de XAH, onde cada drop equivale a 0,000001 XAH. Por exemplo, para especificar 13,1 XAH: + +``` +"13100000" +``` + +**Não especifique XAH como um objeto.** + +Valores de XAH não podem ser negativos. + +#### Valores em Token + +Para especificar um valor de um token (fungível), use um objeto Amount. Este é um objeto JSON com três campos: + +| `Campo` | Tipo | Descrição | +| ---------- | ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| `currency` | String - Código de Moeda | Código de moeda arbitrário para o token. Não pode ser XAH. | +| `value` | String Number | Representação decimal entre aspas da quantidade do token. Pode incluir notação científica, como `1.23e11` significando 123.000.000.000. Tanto `e` quanto `E` podem ser usados. Pode ser negativo ao exibir saldos, mas valores negativos não são permitidos em outros contextos, como ao especificar quanto enviar. | +| `issuer` | String | Geralmente, a conta que emite este token. Em casos especiais, pode se referir à conta que detém o token em vez disso (por exemplo, em uma transação Clawback). | + +**Cuidado:** Esses nomes de campo diferenciam maiúsculas de minúsculas. + +Por exemplo, para representar $153,75 dólares americanos emitidos pela conta `r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59`, você especificaria: + +```json +{ + "currency": "USD", + "value": "153.75", + "issuer": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59" +} +``` + +#### Especificando Sem Valores + +Em alguns casos, você precisa definir um ativo (que pode ser XAH ou um token) sem um valor específico, como ao definir um livro de ordens na exchange descentralizada. + +Para descrever um token sem um valor, especifique-o como um objeto de moeda, mas omita o campo `value`. Por exemplo: + +```json +{ + "currency": "TST", + "issuer": "rP9jPyP5kyvFRb6ZiRghAGw5u8SGAmU4bd" +} +``` + +Para descrever XAH sem um valor, especifique-o como um objeto JSON com _apenas_ um campo `currency`. Nunca inclua um campo `issuer` para XAH. Por exemplo: + +```json +{ + "currency": "XAH" +} +``` + +### Números String + +### Precisão do XAH + +O XAH tem a mesma precisão que um inteiro sem sinal de 64 bits onde cada unidade equivale a 0,000001 XAH. Ele usa matemática inteira, de modo que qualquer valor inferior a um drop completo é arredondado para baixo. + +### Precisão de Token + +Os tokens podem representar uma ampla variedade de ativos, incluindo aqueles normalmente medidos em denominações muito pequenas ou muito grandes. Este formato usa dígitos significativos e um expoente de potência de dez de forma similar à notação científica. O formato suporta dígitos significativos e expoentes positivos e negativos dentro do intervalo especificado. Ao contrário das representações típicas de ponto flutuante de números não inteiros, este formato usa matemática inteira para todos os cálculos, portanto sempre mantém 15 dígitos decimais de precisão. Multiplicação e divisão têm ajustes para compensar o excesso de arredondamento nos dígitos menos significativos. + +Ao enviar valores de token na rede peer-to-peer do Xahau, os servidores serializam o valor para um valor binário de 64 bits. + +**Dica:** Para tokens que não devem ser divisíveis, consulte Tokens Não Fungíveis (NFTs). + +### Códigos de Moeda + +#### Códigos de Moeda Padrão + +O formato padrão para códigos de moeda é uma string de três caracteres, como `USD`. Isso é destinado ao uso com [Códigos de Moeda ISO 4217](https://www.xe.com/iso4217.php). As seguintes regras se aplicam: + +* Os códigos de moeda devem ter exatamente 3 caracteres ASCII de comprimento. Os seguintes caracteres são permitidos: todas as letras maiúsculas e minúsculas, dígitos e os símbolos `?`, `!`, `@`, `#`, `$`, `%`, `^`, `&`, `*`, `<`, `>`, `(`, `)`, `{`, `}`, `[`, `]` e `|`. +* Os códigos de moeda diferenciam maiúsculas de minúsculas. +* O código de moeda XAH (todo maiúsculo) não é permitido. O XAH real normalmente não usa um código de moeda no protocolo do Xahau. + +No nível do protocolo, este formato é serializado em um valor binário de 160 bits começando com `0x00`. + +#### Códigos de Moeda Não Padrão + +Você também pode usar uma string hexadecimal de 160 bits (40 caracteres) como `015841551A748AD2C1F76FF6ECB0CCCD00000000` como código de moeda. Para evitar que isso seja tratado como um código de moeda "padrão", os primeiros 8 bits NÃO DEVEM ser `0x00`. + +**Descontinuado:** Algumas versões anteriores do [ripple-lib](https://github.com/XRPLF/xrpl.js) suportavam um tipo de código de moeda "com juros" ou "com demurrage". Esses códigos têm os primeiros 8 bits `0x01`. Moedas com demurrage/juros não são mais suportadas, mas você pode encontrá-las nos dados do ledger. diff --git a/src/content/docs/br/docs/protocol-reference/data-types/index.mdx b/src/content/docs/br/docs/protocol-reference/data-types/index.mdx new file mode 100644 index 0000000..4050b4c --- /dev/null +++ b/src/content/docs/br/docs/protocol-reference/data-types/index.mdx @@ -0,0 +1,86 @@ +--- +title: Tipos de Dados +--- +Diferentes tipos de objetos são identificados de maneiras únicas: + +Contas são identificadas por seu Endereço, por exemplo `"r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59"`. Os endereços sempre começam com "r". Muitos métodos do `rippled` também aceitam uma representação hexadecimal. + +Transações são identificadas por um Hash do formato binário da transação. Você também pode identificar uma transação pelo número de Sequência e conta remetente. + +Cada Ledger fechado tem um Índice de Ledger e um valor Hash. Ao \[Especificar Ledgers]\[], você pode usar qualquer um deles. + +### Endereços + +### Hashes + +#### Prefixos de Hash + +[\[Fonte\]](https://github.com/Xahau/xahaud/blob/master/src/ripple/protocol/HashPrefix.h) + +Em muitos casos, o Xahau prefixa os dados binários de um objeto com um código de 4 bytes antes de calcular seu hash, para que objetos de tipos diferentes tenham hashes diferentes, mesmo que seus formatos binários sejam iguais. Os códigos de 4 bytes existentes são estruturados como três caracteres alfabéticos, codificados como ASCII, seguidos de um byte zero. + +Alguns tipos de hash aparecem em solicitações e respostas de API. Outros são calculados apenas como o primeiro passo de assinatura de um determinado tipo de dado, ou ao calcular um hash de nível superior. A tabela a seguir mostra todos os prefixos de hash de 4 bytes que o Xahau usa: + +| Tipo de Objeto | Campos de API | Prefixo Hash (Hex) | Prefixo Hash (Texto) | +| ------------------------------------- | -------------------------------- | ------------------ | -------------------- | +| Proposta de consenso | N/A | `0x50525000` | `PRP\0` | +| Versão de Ledger | `ledger_hash` | `0x4C575200` | `LWR\0` | +| Dados de estado do ledger | `account_state` no cabeçalho | `0x4D4C4E00` | `MLN\0` | +| Nó interno de dados de ledger | N/A | `0x4D494E00` | `MIN\0` | +| Nó interno de dados de ledger (SHAMapv2) | N/A | `0x494E5200` | `INR\0` | +| Reivindicação de Canal de Pagamento | N/A | `0x434C4D00` | `CLM\0` | +| Transação assinada | `hash` das transações | `0x54584E00` | `TXN\0` | +| Transação com metadados | N/A | `0x534E4400` | `SND\0` | +| Transação não assinada (assinatura única) | N/A | `0x53545800` | `STX\0` | +| Transação não assinada (multi-assinatura) | N/A | `0x534D5400` | `SMT\0` | +| Voto de validação | N/A | `0x56414C00` | `VAL\0` | +| Manifesto de validador | N/A | `0x4D414E00` | `MAN\0` | + +Os IDs de objetos de ledger são calculados de forma similar, mas usam um prefixo de 2 bytes chamado "chave de espaço" em vez de um prefixo no formato descrito aqui. + +### Sequência da Conta + +### Índice de Ledger + +#### Especificando Ledgers + +Muitos métodos de API exigem que você especifique uma instância do ledger, com os dados recuperados sendo considerados atualizados em relação a essa versão específica do ledger compartilhado. Os comandos que aceitam uma versão de ledger funcionam da mesma forma. Há três maneiras de especificar qual ledger você deseja usar: + +1. Especifique um ledger pelo seu Índice de Ledger no parâmetro `ledger_index`. Cada ledger fechado tem um índice de ledger que é 1 maior que o ledger anterior. (O primeiro ledger tinha índice de ledger 1.) + + ``` + "ledger_index": 61546724 + ``` +2. Especifique um ledger pelo seu valor Hash no parâmetro `ledger_hash`. + + ``` + "ledger_hash": "8BB204CE37CFA7A021A16B5F6143400831C4D1779E6FE538D9AC561ABBF4A929" + ``` +3. Especifique um ledger por um dos seguintes atalhos, no parâmetro `ledger_index`: + * `validated` para o ledger mais recente que foi validado por consenso + + ``` + "ledger_index": "validated" + ``` + * `closed` para o ledger mais recente que foi fechado para modificações e proposto para validação + * `current` para a versão de trabalho atual do servidor do ledger. + +Também há um parâmetro `ledger` descontinuado que aceita qualquer um dos três formatos acima. _Não_ use este parâmetro; ele pode ser removido sem aviso prévio. + +Se você não especificar um ledger, o servidor decide qual ledger usar para atender à solicitação. Por padrão, o servidor escolhe o ledger `current` (em andamento). No Modo de Relatório, o servidor usa o ledger validado mais recente em vez disso. Não forneça mais de um campo especificando ledgers. + +**Nota:** Não dependa do comportamento padrão para especificar um ledger; ele está sujeito a alterações. Sempre especifique uma versão de ledger na solicitação quando puder. + +### Especificando Valores em Moeda + +Existem dois tipos de moedas no Xahau: XAH e tokens. Esses dois tipos de moedas são especificados em formatos diferentes, com diferentes comportamentos de precisão e arredondamento. + +Alguns campos, como o `Amount` de destino de uma \[transação Payment]\[], podem ser de qualquer tipo. Alguns campos aceitam apenas XAH especificamente, como o campo `Fee` (custo de transação). + +O XAH é especificado como uma string contendo um número inteiro de "drops" de XAH, onde 1 milhão de drops equivale a 1 XAH. Os tokens, por sua vez, são especificados como um objeto com campos para o valor decimal, código de moeda e emissor. + +### Especificando Tempo + +O servidor `xahaud` e suas APIs representam o tempo como um inteiro sem sinal. Esse número mede o número de segundos desde a "Época Ripple" de 1º de janeiro de 2000 (00:00 UTC). Isso é similar à forma como a [época Unix](http://en.wikipedia.org/wiki/Unix_time) funciona, exceto que a Época Ripple é 946684800 segundos após a Época Unix. + +Não converta os tempos da Época Ripple para tempos da Época UNIX em variáveis de 32 bits: isso pode levar a overflows de inteiro. diff --git a/src/content/docs/br/docs/protocol-reference/ledger-data/index.mdx b/src/content/docs/br/docs/protocol-reference/ledger-data/index.mdx new file mode 100644 index 0000000..ace5e44 --- /dev/null +++ b/src/content/docs/br/docs/protocol-reference/ledger-data/index.mdx @@ -0,0 +1,31 @@ +--- +title: Dados de Ledger +--- +Cada versão de ledger no Xahau é composta de três partes: + +* **Cabeçalho do Ledger**: Metadados sobre esta versão de ledger em si. +* **Conjunto de Transações**: Todas as transações que foram executadas para criar esta versão de ledger. +* **Dados de Estado**: O registro completo de objetos representando contas, configurações e saldos desta versão de ledger. (Isso também é chamado de "estado da conta".) + +### Dados de Estado + +Os dados de estado de cada versão de ledger são um conjunto de **objetos de ledger**, às vezes chamados de _entradas de ledger_, que coletivamente representam todas as configurações, saldos e relações em um determinado ponto no tempo. Para armazenar ou recuperar um objeto nos dados de estado, o protocolo usa o [**ID do Objeto de Ledger**](/docs/protocol-reference/ledger-data/ledger-object-ids) único desse objeto. + +No protocolo peer, os objetos de ledger têm um [formato binário canônico](/docs/protocol-reference/binary-format). Nas APIs do `xahaud`, os objetos de ledger são representados como objetos JSON. + +Os campos de dados de um objeto de ledger dependem do tipo de objeto; a Rede Xahau suporta os seguintes tipos: + +* [Cabeçalho de Ledger](/docs/protocol-reference/ledger-data/ledger-header) +* [Campos Comuns de Entrada de Ledger](/docs/protocol-reference/ledger-data/ledger-object-ids) +* [Tipos de Entrada de Ledger](/docs/protocol-reference/ledger-data/ledger-objects-types/) + +### Ledgers Expandidos + +O Xahau suporta ledgers expandidos, que permitem tamanhos de ledger maiores além dos limites tradicionais. Os ledgers expandidos permitem que a rede lide com volumes de transações aumentados e dados de estado mais complexos, mantendo desempenho e estabilidade de consenso. + +Quando os ledgers expandidos estão habilitados, o ledger pode acomodar: +- Mais transações por ledger +- Conjuntos de dados de estado maiores +- Maior complexidade nas execuções de Hook + +Os ledgers expandidos são usados automaticamente quando a rede determina que são necessários com base no volume de transações e tamanho do estado. Nenhuma configuração especial é necessária para que os nós participem em ledgers expandidos. diff --git a/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-header.mdx b/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-header.mdx new file mode 100644 index 0000000..a77fbde --- /dev/null +++ b/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-header.mdx @@ -0,0 +1,31 @@ +--- +title: Cabeçalho de Ledger +--- +[\[Fonte\]](https://github.com/ripple/rippled/blob/master/src/ripple/ledger/ReadView.h#L71) + +Cada versão de ledger tem um cabeçalho único que descreve o conteúdo. Você pode consultar as informações do cabeçalho de um ledger com o \[método ledger]\[]. O conteúdo do cabeçalho do ledger é o seguinte: + +| Campo | Tipo JSON | \[Tipo Interno]\[] | Descrição | +| ----------------------- | --------- | ------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| `ledger_index` | String | UInt32 | O \[índice de ledger]\[Índice de Ledger] do ledger. Alguns métodos de API exibem isso como um inteiro entre aspas; outros o exibem como um número JSON nativo. | +| `ledger_hash` | String | Hash256 | O \[SHA-512Half]\[] desta versão de ledger. Isso serve como um identificador único para este ledger e todo o seu conteúdo. | +| `account_hash` | String | Hash256 | O \[SHA-512Half]\[] das informações da árvore de estado deste ledger. | +| `close_time` | Number | UInt32 | O tempo aproximado em que esta versão de ledger foi fechada, como o número de segundos desde a Época Ripple de 2000-01-01 00:00:00. Este valor é arredondado com base no `close_time_resolution`. | +| `closed` | Boolean | Boolean | Se `true`, esta versão de ledger não aceita mais novas transações. (No entanto, a menos que esta versão de ledger seja validada, ela pode ser substituída por uma versão de ledger diferente com um conjunto diferente de transações.) | +| `parent_hash` | String | Hash256 | O valor `ledger_hash` da versão de ledger anterior que é o predecessor direto desta. Se houver versões diferentes do índice de ledger anterior, isso indica de qual delas o ledger foi derivado. | +| `total_coins` | String | UInt64 | O número total de \[drops de XAH]\[] pertencentes a contas no ledger. Isso omite XAH que foi destruído por taxas de transação. A quantidade real de XAH em circulação é menor porque algumas contas são "buracos negros" cujas chaves não são conhecidas por ninguém. | +| `transaction_hash` | String | Hash256 | O \[SHA-512Half]\[] das transações incluídas neste ledger. | +| `close_time_resolution` | Number | Uint8 | Um inteiro no intervalo \[2,120] indicando o número máximo de segundos pelo qual o `close_time` pode ser arredondado. | +| `closeFlags` | (Omitido) | UInt8 | Um mapa de bits de flags relacionados ao fechamento deste ledger. | + +### Índice de Ledger + +### Flags de Fechamento + +O ledger tem apenas um flag definido para `closeFlags`: **`sLCF_NoConsensusTime`** (valor `1`). Se este flag estiver habilitado, significa que os validadores tiveram diferentes tempos de fechamento para o ledger, mas construíram o mesmo ledger, portanto declararam consenso enquanto "concordavam em discordar" sobre o tempo de fechamento. Neste caso, o valor oficial de `close_time` do ledger é 1 segundo após o do ledger pai. + +O campo `closeFlags` não está incluído em nenhuma representação JSON de um ledger, mas está incluído na representação binária de um ledger e é um dos campos que determinam o hash do ledger. + +### Veja Também + +Para conceitos básicos de ledger, consulte Ledgers. diff --git a/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-object-ids.mdx b/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-object-ids.mdx new file mode 100644 index 0000000..b7897e3 --- /dev/null +++ b/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-object-ids.mdx @@ -0,0 +1,21 @@ +--- +title: IDs de Objetos de Ledger +--- +[\[Fonte\]](https://github.com/ripple/rippled/blob/master/src/ripple/protocol/impl/Indexes.cpp) + +Cada objeto nos dados de estado de um ledger tem um ID único. O ID é derivado pelo hash dos conteúdos importantes do objeto, juntamente com um [identificador de namespace](https://github.com/ripple/rippled/blob/master/src/ripple/protocol/LedgerFormats.h#L99). O tipo de objeto de ledger determina qual identificador de namespace usar e quais conteúdos incluir no hash. Isso garante que cada ID seja único. Para calcular o hash, o `xahaud` usa SHA-512 e depois trunca o resultado para os primeiros 256 bits. Esse algoritmo, informalmente chamado de **SHA-512Half**, fornece uma saída com segurança comparável ao SHA-256, mas executa mais rápido em processadores de 64 bits. + +Geralmente, o ID de um objeto de ledger é retornado como o campo `index` em JSON, no mesmo nível que o conteúdo do objeto. Nos metadados de transação, o ID do objeto de ledger em JSON é `LedgerIndex`. + +**Dica:** O campo `index` ou `LedgerIndex` de um objeto no ledger é o ID do objeto de ledger. Isso não é o mesmo que um \[índice de ledger]\[]. + +### Flags + +Flags são configurações ligadas/desligadas, representadas como valores binários que são combinados em um único número usando operações bitwise-OR. Os valores de bits para os flags nas entradas de ledger são diferentes dos valores usados para habilitar ou desabilitar esses flags em uma transação. Os flags de estado de ledger têm nomes que começam com **`lsf`**. + +Os valores possíveis para o campo de flags variam com base no tipo de entrada de ledger. Alguns tipos de entrada de ledger não têm flags definidos. Nesses casos, o campo `Flags` sempre tem o valor `0`. + +### Veja Também + +* Para mais informações sobre como o Xahau cria e usa hashes, consulte Hashes. +* Para conceitos básicos de ledger, consulte Ledgers. diff --git a/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/accountroot.mdx b/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/accountroot.mdx new file mode 100644 index 0000000..bfb6c22 --- /dev/null +++ b/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/accountroot.mdx @@ -0,0 +1,83 @@ +--- +title: AccountRoot +--- +[\[Fonte\]](https://github.com/Xahau/xahaud/blob/264280edd79b7f764536e02459f33f66a59c0531/src/ripple/protocol/impl/LedgerFormats.cpp#L36-L60) + +Um tipo de entrada de ledger `AccountRoot` descreve uma única conta, suas configurações e saldo em XAH. + +### Exemplo JSON + +```json +{ + "Account": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn", + "AccountTxnID": "0D5FB50FA65C9FE1538FD7E398FFFE9D1908DFA4576D8D7A020040686F93C77D", + "AccountIndex": "59", + "Balance": "148446663", + "Domain": "6D64756F31332E636F6D", + "HookStateScale": 10, + "EmailHash": "98B4375E1D753E5B91627516F6D70977", + "Flags": 8388608, + "LedgerEntryType": "AccountRoot", + "MessageKey": "0000000000000000000000070000000300", + "OwnerCount": 3, + "PreviousTxnID": "0D5FB50FA65C9FE1538FD7E398FFFE9D1908DFA4576D8D7A020040686F93C77D", + "PreviousTxnLgrSeq": 14091160, + "Sequence": 336, + "TransferRate": 1004999999, + "index": "13F1A95D7AAB7108D5CE7EEAF504B2894B8C674E6D68499076441C4837282BF8" +} +``` + +### Campos + +Um objeto `AccountRoot` tem os seguintes campos: + +| Campo | Tipo JSON | \[Tipo Interno]\[] | Obrigatório? | Descrição | +| ---------------------- | --------- | ------------------- | ----------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `Account` | String | AccountID | Sim | O endereço (clássico) de identificação desta conta. | +| `Sequence` | Number | UInt32 | Sim | O número de sequência da próxima transação válida para esta conta. | +| `Balance` | String | Amount | Não | O saldo atual em [XAH em drops][drops de XAH] desta conta, representado como uma string. | +| `OwnerCount` | Number | UInt32 | Sim | O número de objetos que esta conta possui no ledger, o que contribui para sua reserva de proprietário. | +| `PreviousTxnID` | String | Hash256 | Sim | O hash identificador da transação que mais recentemente modificou este objeto. | +| `PreviousTxnLgrSeq` | Number | UInt32 | Sim | O \[índice do ledger]\[Índice de Ledger] que contém a transação que mais recentemente modificou este objeto. | +| `AccountTxnID` | String | Hash256 | Não | O hash identificador da transação mais recentemente enviada por esta conta. Este campo deve ser habilitado para usar o campo de transação `AccountTxnID`. Para habilitá-lo, envie uma transação AccountSet com o flag `asfAccountTxnID` ativado. | +| `RegularKey` | String | AccountID | Não | O endereço de um par de chaves que pode ser usado para assinar transações desta conta em vez da chave mestre. Use uma \[transação SetRegularKey]\[] para alterar este valor. | +| `EmailHash` | String | Hash128 | Não | O hash md5 de um endereço de e-mail. Clientes podem usar isso para buscar um avatar em serviços como [Gravatar](https://en.gravatar.com/). | +| `WalletLocator` | String | Hash256 | Não | Um valor arbitrário de 256 bits que os usuários podem definir. | +| `WalletSize` | Number | UInt32 | Não | Não utilizado. (O código suporta este campo, mas não há maneira de defini-lo.) | +| `MessageKey` | String | Blob | Não | Uma chave pública que pode ser usada para enviar mensagens criptografadas para esta conta. Em JSON, usa hexadecimal. Deve ter exatamente 33 bytes, com o primeiro byte indicando o tipo de chave: `0x02` ou `0x03` para chaves secp256k1, `0xED` para chaves Ed25519. | +| `TransferRate` | Number | UInt32 | Não | Uma taxa de transferência a cobrar de outros usuários que enviam moeda emitida por esta conta entre si. | +| `Domain` | String | Blob | Não | Um domínio associado a esta conta. Em JSON, é o hexadecimal da representação ASCII do domínio. [Não pode ter mais de 256 bytes de comprimento.](https://github.com/Xahau/xahaud/blob/55dc7a252e08a0b02cd5aa39e9b4777af3eafe77/src/ripple/app/tx/impl/SetAccount.h#L34) | +| `TickSize` | Number | UInt8 | Não | Quantos dígitos significativos usar para taxas de câmbio de Ofertas envolvendo moedas emitidas por este endereço. Valores válidos são de `3` a `15`, inclusive. _(Adicionado pela \[emenda TickSize]\[].)_ | +| `TicketCount` | Number | UInt32 | Não | Quantos Tickets esta conta possui no ledger. Atualizado automaticamente para garantir que a conta permaneça abaixo do limite máximo de 250 Tickets. Este campo é omitido se a conta tiver zero Tickets. _(Adicionado pela \[emenda TicketBatch]\[].)_ | +| `NFTokenMinter` | String | AccountID | Não | Outra conta que pode cunhar tokens não fungíveis em nome desta conta. _(Adicionado pela \[emenda NonFungibleTokensV1_1]\[])_ | +| `MintedNFTokens` | Number | UInt32 | Não | Quantos tokens não fungíveis no total foram cunhados por e em nome desta conta. _(Adicionado pela \[emenda NonFungibleTokensV1_1]\[])_ | +| `BurnedNFTokens` | Number | UInt32 | Não | Quantos tokens não fungíveis emitidos por esta conta foram queimados no total. Este número é sempre igual ou menor que `MintedNFTokens`. | +| `HookStateCount` | Number | UInt32 | Não | O número de estados no Hook. | +| `HookNamespaces` | Array | Vector256 | Não | Um valor único para evitar conflitos de estado entre múltiplos Hooks instalados na mesma conta XAHL. | +| `RewardLgrFirst` | Number | UInt32 | Não | O número do ledger da última transação ClaimReward. | +| `RewardLgrLast` | Number | UInt32 | Não | O número de sequência do ledger da última transação de entrada ou saída da sua conta. | +| `RewardTime` | Number | UInt32 | Não | O tempo de ledger em que a última recompensa foi reivindicada. | +| `RewardAccumulator` | String | UInt64 | Não | A área sob o gráfico saldo-tempo da sua conta desde a última transação ClaimReward. | +| `FirstNFTokenSequence` | Number | UInt32 | Não | O \[Número de Sequência]\[] da conta no momento em que cunhou seu primeiro token não fungível. _(Adicionado pela \[emenda fixNFTokenRemint]\[] :not_enabled:)_ | +| `ImportSequence` | Number | UInt32 | Não | O número de sequência atual da conta importadora no XAHL Ledger. | +| `GovernanceFlags` | String | Hash256 | Não | | +| `GovernanceMarks` | String | Hash256 | Não | | +| `AccountIndex` | String | UInt64 | Não | O número de índice de criação da conta. _(Adicionado pela \[emenda xahauGenesis]\[] :enabled:)_ | +| `TouchCount` | String | UInt64 | Não | Um contador incremental para cada vez que a entrada de ledger é "tocada". | +| `HookStateScale` | Number | UInt16 | Não | Fator de escala para determinar quando entradas de estado de Hook se tornam obsoletas. Valores válidos são de `1` a `16` inclusive. _(Adicionado pela [emenda ExtendedHookState][].)_ | + +### Flags de AccountRoot + +Existem várias opções que podem ser habilitadas ou desabilitadas para uma conta. Essas opções podem ser alteradas com uma \[transação AccountSet]\[]. No ledger, os flags são representados como valores binários que podem ser combinados com operações bitwise-or. Os valores de bits para os flags no ledger são diferentes dos valores usados para habilitar ou desabilitar esses flags em uma transação. Os flags de ledger têm nomes que começam com **`lsf`**. + +Objetos AccountRoot podem ter os seguintes valores de flag: + +
Nome do FlagValor HexValor DecimalFlag AccountSet CorrespondenteDescrição
lsfDefaultRipple0x008000008388608asfDefaultRippleHabilita rippling nas linhas de confiança deste endereço por padrão. Obrigatório para endereços emissores; desencorajado para outros.
lsfDepositAuth0x0100000016777216asfDepositAuthEsta conta tem DepositAuth habilitado, o que significa que só pode receber fundos de transações que ela mesma envia e de contas pré-autorizadas. (Adicionado pela [emenda DepositAuth][])
lsfDisableMaster0x001000001048576asfDisableMasterProíbe o uso da chave mestre para assinar transações desta conta.
lsfDisallowIncomingCheck0x08000000134217728asfDisallowIncomingCheckEsta conta bloqueia Checks recebidos.
lsfDisallowIncomingNFTokenOffer0x0400000067108864asfDisallowIncomingNFTokenOfferEsta conta bloqueia NFTokenOffers recebidas.
lsfDisallowIncomingPayChan0x10000000268435456asfDisallowIncomingPayChanEsta conta bloqueia Canais de Pagamento recebidos.
lsfDisallowIncomingTrustline0x20000000536870912asfDisallowIncomingTrustlineEsta conta bloqueia linhas de confiança recebidas.
lsfDisallowIncomingRemit0x800000002147483648asfDisallowIncomingRemitEsta conta bloqueia transações remit recebidas.
lsfDisallowXRP0x00080000524288asfDisallowXRPAplicações clientes não devem enviar XAH para esta conta. (Consultivo; não aplicado pelo protocolo.)
lsfGlobalFreeze0x004000004194304asfGlobalFreezeTodos os ativos emitidos por esta conta estão congelados.
lsfNoFreeze0x002000002097152asfNoFreezeEsta conta não pode congelar linhas de confiança conectadas a ela. Uma vez habilitado, não pode ser desabilitado.
lsfPasswordSpent0x0001000065536(Nenhum)Esta conta usou sua transação gratuita SetRegularKey.
lsfRequireAuth0x00040000262144asfRequireAuthEsta conta deve aprovar individualmente outros usuários para que eles possam deter os tokens desta conta.
lsfRequireDestTag0x00020000131072asfRequireDestExige que pagamentos recebidos especifiquem uma Tag de Destino.
lsfTshCollect0x0200000033554432asfTshCollectO TSH paga pela execução de sua própria Cadeia de Hook.
lsfURITokenIssuer0x0400000067108864asfURITokenIssuerEsta conta não pode ser excluída após ter emitido um URIToken.
+ +### Formato do ID do AccountRoot + +O ID de um objeto AccountRoot é o \[SHA-512Half]\[] dos seguintes valores, concatenados em ordem: + +* A chave de espaço Account (`0x0061`) +* O AccountID da conta diff --git a/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/amendments.mdx b/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/amendments.mdx new file mode 100644 index 0000000..bd9afb0 --- /dev/null +++ b/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/amendments.mdx @@ -0,0 +1,60 @@ +--- +title: Amendments +--- +[\[Fonte\]](https://github.com/ripple/rippled/blob/master/src/ripple/protocol/impl/LedgerFormats.cpp#L138-L144) + +O tipo de objeto `Amendments` contém uma lista de Emendas atualmente ativas. Cada versão de ledger contém **no máximo um** objeto `Amendments`. + +### Exemplo JSON + +```json +{ + "Majorities": [ + { + "Majority": { + "Amendment": "1562511F573A19AE9BD103B5D6B9E01B3B46805AEC5D3C4805C902B514399146", + "CloseTime": 535589001 + } + } + ], + "Amendments": [ + "42426C4D4F1009EE67080A9B7965B44656D7714D104A72F9B4369F97ABF044EE", + "4C97EBA926031A7CF7D7B36FDE3ED66DDA5421192D63DE53FFB46E43B9DC8373", + "6781F8368C4771B83E8B821D88F580202BCB4228075297B19E4FDC5233F1EFDC", + "740352F2412A9909880C23A559FCECEDA3BE2126FED62FC7660D628A06927F11" + ], + "Flags": 0, + "LedgerEntryType": "Amendments", + "index": "7DB0788C020F02780A673DC74757F23823FA3014C1866E72CC4CD8B226CD6EF4" +} +``` + +### Campos + +| Nome | Tipo JSON | \[Tipo Interno]\[] | Obrigatório? | Descrição | +| ----------------- | --------- | ------------------- | ------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `Amendments` | Array | Vector256 | Não | Array de IDs de emenda de 256 bits para todas as emendas atualmente habilitadas. Se omitido, não há emendas habilitadas. | +| `Flags` | Number | UInt32 | Sim | Um mapa de bits de flags booleanos habilitados para este objeto. Atualmente, o protocolo não define flags para objetos `Amendments`. O valor é sempre `0`. | +| `LedgerEntryType` | String | UInt16 | Sim | O valor `0x0066`, mapeado para a string `Amendments`, indica que este objeto descreve o status das emendas no Xahau. | +| `Majorities` | Array | STArray | Não | Array de objetos descrevendo o status das emendas que têm suporte majoritário, mas ainda não estão habilitadas. Se omitido, não há emendas pendentes com suporte majoritário. | + +Cada membro do campo `Majorities`, se presente, é um objeto com um campo, `Majority`, cujo conteúdo é um objeto aninhado com os seguintes campos: + +| Nome | Tipo JSON | \[Tipo Interno]\[] | Descrição | +| ----------- | --------- | ------------------- | ---------------------------------------------------------------------------------------------------------------------- | +| `Amendment` | String | Hash256 | O ID da emenda pendente. | +| `CloseTime` | Number | UInt32 | O campo `close_time` da versão de ledger em que esta emenda obteve maioria mais recentemente. | + +No processo de emenda, um consenso de validadores adiciona uma nova emenda ao campo `Majorities` usando uma pseudo-transação \[EnableAmendment]\[] com o flag `tfGotMajority` quando 80% ou mais dos validadores a apoiam. Se o suporte a uma emenda pendente cair abaixo de 80%, uma pseudo-transação \[EnableAmendment]\[] com o flag `tfLostMajority` remove a emenda do array `Majorities`. Se uma emenda permanecer no campo `Majorities` por pelo menos 2 semanas, uma pseudo-transação \[EnableAmendment]\[] sem flags a remove de `Majorities` e a adiciona permanentemente ao campo `Amendments`. + +**Nota:** Tecnicamente, todas as transações em um ledger são processadas com base nas emendas habilitadas na versão de ledger imediatamente anterior. Ao aplicar transações a uma versão de ledger em que uma emenda é habilitada, as regras não mudam no meio do ledger. Após o fechamento do ledger, o próximo ledger usa as novas regras definidas por quaisquer novas emendas que se apliquem. + +### Formato do ID do Amendments + +O ID do objeto `Amendments` é o hash da chave de espaço `Amendments` (`0x0066`) apenas. Isso significa que o ID do objeto `Amendments` em um ledger é sempre: + +``` +7DB0788C020F02780A673DC74757F23823FA3014C1866E72CC4CD8B226CD6EF4 +``` + +(Não confunda o ID do tipo de objeto de ledger `Amendments` com o ID de Emenda de uma emenda individual.) diff --git a/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/check.mdx b/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/check.mdx new file mode 100644 index 0000000..a5a2536 --- /dev/null +++ b/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/check.mdx @@ -0,0 +1,58 @@ +--- +title: Check +--- +[\[Fonte\]](https://github.com/ripple/rippled/blob/master/src/ripple/protocol/impl/LedgerFormats.cpp#L157-L170) + +_(Adicionado pela \[emenda Checks]\[].)_ + +Um objeto `Check` descreve um cheque, similar a um cheque pessoal em papel, que pode ser descontado pelo destinatário para obter dinheiro do remetente. (O pagamento potencial já foi aprovado pelo remetente, mas nenhum dinheiro se move até que seja descontado. Diferente de um Escrow, o dinheiro para um Check não é reservado, então descontar o Check pode falhar por falta de fundos.) + +### Exemplo JSON + +```json +{ + "Account": "rUn84CUYbNjRoTQ6mSW7BVJPSVJNLb1QLo", + "Destination": "rfkE1aSy9G8Upk4JssnwBxhEv5p4mn2KTy", + "DestinationNode": "0000000000000000", + "DestinationTag": 1, + "Expiration": 570113521, + "Flags": 0, + "InvoiceID": "46060241FABCF692D4D934BA2A6C4427CD4279083E38C77CBE642243E43BE291", + "LedgerEntryType": "Check", + "OwnerNode": "0000000000000000", + "PreviousTxnID": "5463C6E08862A1FAE5EDAC12D70ADB16546A1F674930521295BC082494B62924", + "PreviousTxnLgrSeq": 6, + "SendMax": "100000000", + "Sequence": 2, + "index": "49647F0D748DC3FE26BDACBC57F251AADEFFF391403EC9BF87C97F67E9977FB0" +} +``` + +### Campos + +Um objeto `Check` tem os seguintes campos: + +| Campo | Tipo JSON | \[Tipo Interno]\[] | Obrigatório? | Descrição | +| ------------------- | ---------------- | ------------------- | ------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `Account` | String | Account | Sim | O remetente do Check. Descontar o Check debita o saldo deste endereço. | +| `Destination` | String | Account | Sim | O destinatário pretendido do Check. Apenas este endereço pode descontar o Check, usando uma \[transação CheckCash]\[]. | +| `DestinationNode` | String | UInt64 | Não | Uma dica indicando qual página do diretório do proprietário do destinatário aponta para este objeto, caso o diretório consista em múltiplas páginas. | +| `DestinationTag` | Number | UInt32 | Não | Uma tag arbitrária para especificar melhor o destino deste Check, como um destinatário hospedado no endereço de destino. | +| `Expiration` | Number | UInt32 | Não | Indica o tempo após o qual este Check é considerado expirado. Consulte \[Especificando Tempo]\[] para detalhes. | +| `Flags` | Number | UInt32 | Sim | Um mapa de bits de flags booleanos habilitados para este objeto. Atualmente, o protocolo não define flags para objetos `Check`. O valor é sempre `0`. | +| `InvoiceID` | String | Hash256 | Não | Hash de 256 bits arbitrário fornecido pelo remetente como razão ou identificador específico para este Check. | +| `LedgerEntryType` | String | UInt16 | Sim | O valor `0x0043`, mapeado para a string `Check`, indica que este objeto é um objeto Check. | +| `OwnerNode` | String | UInt64 | Sim | Uma dica indicando qual página do diretório do proprietário do remetente aponta para este objeto, caso o diretório consista em múltiplas páginas. **Nota:** O objeto não contém um link direto para o diretório do proprietário que o contém, pois esse valor pode ser derivado de `Account`. | +| `PreviousTxnID` | String | Hash256 | Sim | O hash identificador da transação que mais recentemente modificou este objeto. | +| `PreviousTxnLgrSeq` | Number | UInt32 | Sim | O \[índice do ledger]\[Índice de Ledger] que contém a transação que mais recentemente modificou este objeto. | +| `SendMax` | String ou Object | Amount | Sim | O valor máximo de moeda que este Check pode debitar do remetente. Se o Check for descontado com sucesso, o destinatário é creditado na mesma moeda por até esse valor. | +| `Sequence` | Number | UInt32 | Sim | O número de sequência da \[transação CheckCreate]\[] que criou este check. | +| `SourceTag` | Number | UInt32 | Não | Uma tag arbitrária para especificar melhor a origem deste Check, como um destinatário hospedado no endereço do remetente. | + +### Formato do ID do Check + +O ID de um objeto `Check` é o \[SHA-512Half]\[] dos seguintes valores, concatenados em ordem: + +* A chave de espaço Check (`0x0043`) +* O AccountID do remetente da \[transação CheckCreate]\[] que criou o objeto `Check` +* O número `Sequence` da \[transação CheckCreate]\[] que criou o objeto `Check`. Se a transação CheckCreate usou um Ticket, use o valor `TicketSequence` em vez disso. diff --git a/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/cron.mdx b/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/cron.mdx new file mode 100644 index 0000000..b3cc6ee --- /dev/null +++ b/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/cron.mdx @@ -0,0 +1,57 @@ +--- +title: Cron +--- +[\[Fonte\]](https://github.com/Xahau/xahaud/blob/dev/src/ripple/protocol/impl/LedgerFormats.cpp) + +_(Adicionado pela [emenda Cron][].)_ + +Um objeto `Cron` representa uma execução agendada de Hook criada por uma [transação CronSet](/docs/protocol-reference/transactions/transaction-types/cronset). O mecanismo Cron insere automaticamente pseudo-transações do tipo `Cron` no ledger quando execuções agendadas estão vencidas. + +### Exemplo JSON + +```json +{ + "Owner": "rWYkbWkCeg8dP6rXALnjgZSjjLyih5NXm", + "OwnerNode": "0000000000000000", + "StartTime": 816348759, + "RepeatCount": 3, + "DelaySeconds": 120, + "PreviousTxnID": "5463C6E08862A1FAE5EDAC12D70ADB16546A1F674930521295BC082494B62924", + "PreviousTxnLgrSeq": 6, + "LedgerEntryType": "Cron", + "index": "49647F0D748DC3FE26BDACBC57F251AADEFFF391403EC9BF87C97F67E9977FB0" +} +``` + +### Campos + +Um objeto `Cron` tem os seguintes campos: + +| Campo | Tipo JSON | \[Tipo Interno]\[] | Obrigatório? | Descrição | +| ------------------- | --------- | ------------------- | ------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `Owner` | String | AccountID | Sim | A conta que possui a execução agendada de Hook. Esta é a conta que será invocada quando o cron executar. | +| `OwnerNode` | String | UInt64 | Sim | Uma dica indicando qual página do diretório do proprietário aponta para este objeto, caso o diretório consista em múltiplas páginas. **Nota:** O objeto não contém um link direto para o diretório do proprietário que o contém, pois esse valor pode ser derivado de `Owner`. | +| `StartTime` | Number | UInt32 | Sim | Timestamp da Época Ripple para quando a primeira execução deve ocorrer. Use `0` para execução imediata. Consulte \[Especificando Tempo]\[] para detalhes. | +| `RepeatCount` | Number | UInt32 | Sim | Número de vezes que o cron deve executar. Pode ser estendido via [transações CronSet](/docs/protocol-reference/transactions/transaction-types/cronset) subsequentes. Máximo de 256 por transação, mas pode ser estendido além deste limite. | +| `DelaySeconds` | Number | UInt32 | Sim | Intervalo de tempo em segundos entre cada execução. Máximo de 31.536.000 segundos (365 dias). | +| `PreviousTxnID` | String | Hash256 | Sim | O hash identificador da transação que mais recentemente modificou este objeto. | +| `PreviousTxnLgrSeq` | Number | UInt32 | Sim | O \[índice do ledger]\[Índice de Ledger] que contém a transação que mais recentemente modificou este objeto. | +| `LedgerEntryType` | String | UInt16 | Sim | O valor `0x0061`, mapeado para a string `Cron`, indica que este objeto é um objeto Cron. | + +### Formato do ID do Cron + +O ID de um objeto `Cron` é o \[SHA-512Half]\[] dos seguintes valores, concatenados em ordem: + +* A chave de espaço Cron (`0x0076`) +* O timestamp do campo `StartTime` +* O AccountID aleatorizado do campo `Owner` + +### Comportamento de Execução + +Quando um cron está pronto para executar, o mecanismo Cron insere uma pseudo-transação do tipo `Cron` no ledger. Essa pseudo-transação contém um campo `Owner` referenciando a conta Hook de origem. O Hook agendado será invocado automaticamente nos intervalos especificados sem exigir acionadores externos. + +Desenvolvedores de Hook devem habilitar collect calls (flag `hsfCOLLECT`) em seus Hooks, pois o `Owner` constitui um stakeholder transacional fraco (TSH) quando a pseudo-transação Cron executa. + +### Transações Relacionadas + +* [Transação CronSet](/docs/protocol-reference/transactions/transaction-types/cronset): Cria, atualiza ou exclui um objeto Cron diff --git a/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/deposit-pre-auth.mdx b/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/deposit-pre-auth.mdx new file mode 100644 index 0000000..46ba0aa --- /dev/null +++ b/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/deposit-pre-auth.mdx @@ -0,0 +1,45 @@ +--- +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) diff --git a/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/directory-node.mdx b/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/directory-node.mdx new file mode 100644 index 0000000..3a8c266 --- /dev/null +++ b/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/directory-node.mdx @@ -0,0 +1,96 @@ +--- +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.) diff --git a/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/emitted-txn.mdx b/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/emitted-txn.mdx new file mode 100644 index 0000000..42d5b08 --- /dev/null +++ b/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/emitted-txn.mdx @@ -0,0 +1,61 @@ +--- +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. | diff --git a/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/escrow.mdx b/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/escrow.mdx new file mode 100644 index 0000000..8c445cb --- /dev/null +++ b/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/escrow.mdx @@ -0,0 +1,67 @@ +--- +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. diff --git a/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/fee-settings.mdx b/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/fee-settings.mdx new file mode 100644 index 0000000..d5e163c --- /dev/null +++ b/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/fee-settings.mdx @@ -0,0 +1,64 @@ +--- +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 +``` diff --git a/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/hook-definition.mdx b/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/hook-definition.mdx new file mode 100644 index 0000000..734463e --- /dev/null +++ b/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/hook-definition.mdx @@ -0,0 +1,58 @@ +--- +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 diff --git a/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/hook-state.mdx b/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/hook-state.mdx new file mode 100644 index 0000000..e78faf6 --- /dev/null +++ b/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/hook-state.mdx @@ -0,0 +1,42 @@ +--- +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. diff --git a/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/hook.mdx b/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/hook.mdx new file mode 100644 index 0000000..7238950 --- /dev/null +++ b/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/hook.mdx @@ -0,0 +1,57 @@ +--- +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 diff --git a/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/import-vl-sequence.mdx b/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/import-vl-sequence.mdx new file mode 100644 index 0000000..b068661 --- /dev/null +++ b/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/import-vl-sequence.mdx @@ -0,0 +1,36 @@ +--- +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 diff --git a/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/index.mdx b/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/index.mdx new file mode 100644 index 0000000..cac4613 --- /dev/null +++ b/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/index.mdx @@ -0,0 +1,21 @@ +--- +title: Tipos de Objetos de Ledger +--- +import { Aside } from '@astrojs/starlight/components'; + +## Campos Comuns de Entrada de Ledger + +[\[Fonte\]](https://github.com/Xahau/xahaud/blob/master/src/ripple/protocol/impl/LedgerFormats.cpp) + +Cada entrada nos dados de estado de um ledger tem o mesmo conjunto de campos comuns, além de campos adicionais baseados no tipo de entrada de ledger. Os nomes dos campos diferenciam maiúsculas de minúsculas. Os campos comuns para todas as entradas de ledger são: + +| Campo | Tipo JSON | Tipo Interno | Obrigatório? | Descrição | +| ------------------------ | --------- | ------------- | ------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `index` ou `LedgerIndex` | String | Hash256 | Não | O ID único para esta entrada de ledger. Em JSON, este campo é representado com nomes diferentes dependendo do contexto e do método de API. (Observe que, embora seja especificado como "opcional" no código, toda entrada de ledger deve ter um, a menos que sejam dados legados do início do histórico do XRP Ledger.) | +| `LedgerEntryType` | String | UInt16 | Sim | O tipo de entrada de ledger. Os tipos de entrada de ledger válidos incluem `AccountRoot`, `Offer`, `RippleState` e outros. | +| `Flags` | Number | UInt32 | Sim | Conjunto de flags de bits para esta entrada de ledger. | +| `Remarks` | Array | STArray | Não | Array de objetos de observação a definir, atualizar ou excluir (consulte o Formato de Observações) | + + diff --git a/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/ledger-hashes.mdx b/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/ledger-hashes.mdx new file mode 100644 index 0000000..02a2acb --- /dev/null +++ b/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/ledger-hashes.mdx @@ -0,0 +1,72 @@ +--- +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. diff --git a/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/negative-unl.mdx b/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/negative-unl.mdx new file mode 100644 index 0000000..612e554 --- /dev/null +++ b/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/negative-unl.mdx @@ -0,0 +1,53 @@ +--- +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 +``` diff --git a/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/offer.mdx b/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/offer.mdx new file mode 100644 index 0000000..3cce2ed --- /dev/null +++ b/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/offer.mdx @@ -0,0 +1,68 @@ +--- +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: + +
Flag NameHex ValueDecimal ValueCorresponding OfferCreate FlagDescription
lsfPassive0x0001000065536tfPassiveThe object was placed as a passive Offer. This has no effect on the object in the ledger.
lsfSell0x00020000131072tfSellThe object was placed as a sell Offer. This has no effect on the object in the ledger (because tfSell only matters if you get a better rate than you asked for, which cannot happen after the object enters the ledger).
+ +### 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. diff --git a/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/pay-channel.mdx b/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/pay-channel.mdx new file mode 100644 index 0000000..e7ec5c6 --- /dev/null +++ b/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/pay-channel.mdx @@ -0,0 +1,99 @@ +--- +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. diff --git a/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/ripple-state.mdx b/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/ripple-state.mdx new file mode 100644 index 0000000..5bb3e18 --- /dev/null +++ b/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/ripple-state.mdx @@ -0,0 +1,120 @@ +--- +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) diff --git a/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/signers-list.mdx b/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/signers-list.mdx new file mode 100644 index 0000000..2c8354c --- /dev/null +++ b/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/signers-list.mdx @@ -0,0 +1,98 @@ +--- +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`) diff --git a/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/ticket.mdx b/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/ticket.mdx new file mode 100644 index 0000000..0a57972 --- /dev/null +++ b/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/ticket.mdx @@ -0,0 +1,44 @@ +--- +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 diff --git a/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/unl-report.mdx b/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/unl-report.mdx new file mode 100644 index 0000000..be49225 --- /dev/null +++ b/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/unl-report.mdx @@ -0,0 +1,63 @@ +--- +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 +``` diff --git a/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/uritoken.mdx b/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/uritoken.mdx new file mode 100644 index 0000000..40b87b6 --- /dev/null +++ b/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/uritoken.mdx @@ -0,0 +1,59 @@ +--- +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 diff --git a/src/content/docs/br/docs/protocol-reference/transactions/index.mdx b/src/content/docs/br/docs/protocol-reference/transactions/index.mdx new file mode 100644 index 0000000..d0ca6ef --- /dev/null +++ b/src/content/docs/br/docs/protocol-reference/transactions/index.mdx @@ -0,0 +1,6 @@ +--- +title: Transações +--- +## Referência de Transações + +Uma _Transação_ é a única maneira de causar mudanças no Xahau. Os resultados das transações só são definitivos se forem assinados, enviados e aceitos em uma versão de ledger validada após o processo de consenso. Algumas regras do ledger também geram _pseudo-transações_, que não são assinadas ou enviadas, mas ainda devem ser aceitas por consenso. Transações que falham também são incluídas nos ledgers porque modificam saldos de XAH para pagar o \[custo de transação]\[] anti-spam. diff --git a/src/content/docs/br/docs/protocol-reference/transactions/pseudo-transaction-types/cron.mdx b/src/content/docs/br/docs/protocol-reference/transactions/pseudo-transaction-types/cron.mdx new file mode 100644 index 0000000..dc959b9 --- /dev/null +++ b/src/content/docs/br/docs/protocol-reference/transactions/pseudo-transaction-types/cron.mdx @@ -0,0 +1,60 @@ +--- +title: Cron +description: >- + A pseudo-transação Cron é automaticamente inserida pelo motor Cron quando + uma execução de Hook agendada está devida. +--- +\[[Fonte](https://github.com/Xahau/xahaud/blob/dev/src/ripple/app/tx/impl/Cron.cpp)] + +_(Adicionado pela [emenda Cron][].)_ + +A pseudo-transação `Cron` é automaticamente inserida no ledger pelo motor Cron quando uma execução de Hook agendada está devida. Esta pseudo-transação aciona a execução do Hook na conta especificada no campo `Owner`. + +### Exemplo + +```json +{ + "TransactionType": "Cron", + "Account": "rrrrrrrrrrrrrrrrrrrrrhoLvTp", + "Fee": "0", + "LedgerSequence": 21225473, + "Sequence": 0, + "SigningPubKey": "", + "TxnSignature": "", + "Owner": "rWYkbWkCeg8dP6rXALnjgZSjjLyih5NXm" +} +``` + +### Campos + +| Campo | Tipo JSON | \[Tipo Interno]\[] | Descrição | +| ---------------- | --------- | ------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| `Owner` | String | AccountID | A conta que possui a execução de Hook agendada. Esta é a conta que será invocada quando o cron executar. | +| `LedgerSequence` | Number | UInt32 | O \[índice de ledger]\[] onde esta pseudo-transação aparece. Isso distingue a pseudo-transação de outras ocorrências da mesma mudança. | + +### Campos Comuns + +Como pseudo-transação, `Cron` usa os valores padrão de pseudo-transação para campos comuns: + +| Campo | Valor | +| -------------- | ---------------------------------------------- | +| `Account` | `rrrrrrrrrrrrrrrrrrrrrhoLvTp` (`ACCOUNT_ZERO`) | +| `Fee` | `0` | +| `Sequence` | `0` | +| `SigningPubKey`| `""` (string vazia) | +| `TxnSignature` | `""` (string vazia) | + +### Comportamento de Execução + +Quando um [objeto de ledger Cron](/docs/protocol-reference/ledger-data/ledger-objects-types/cron) está pronto para executar (com base nos campos `StartTime`, `DelaySeconds` e `RepeatCount`), o motor Cron insere automaticamente uma pseudo-transação `Cron` no ledger. + +A pseudo-transação contém um campo `Owner` que referencia a conta com o Hook agendado. O Hook nessa conta será invocado automaticamente, e a conta é tratada como um **parte interessada transacional fraca (TSH)** durante a execução. + +**Importante:** Os desenvolvedores de Hook devem habilitar chamadas de coleta (flag `hsfCOLLECT`) em seus Hooks, pois o `Owner` constitui uma parte interessada transacional fraca quando a pseudo-transação Cron é executada. A conta também deve ter o flag `asfTshCollect` habilitado. + +### Documentação Relacionada + +* [Transação CronSet](/docs/protocol-reference/transactions/transaction-types/cronset): Cria, atualiza ou exclui execuções de Hook agendadas +* [Objeto de ledger Cron](/docs/protocol-reference/ledger-data/ledger-objects-types/cron): O objeto de ledger que representa uma execução de Hook agendada +* [Fraco e Forte](/docs/hooks/concepts/weak-and-strong): Entendendo partes interessadas transacionais +* [Hooks de Chamada de Coleta](/docs/hooks/concepts/collect-call): Como Hooks de TSH fraco são executados diff --git a/src/content/docs/br/docs/protocol-reference/transactions/pseudo-transaction-types/emitfailure.mdx b/src/content/docs/br/docs/protocol-reference/transactions/pseudo-transaction-types/emitfailure.mdx new file mode 100644 index 0000000..ed535fc --- /dev/null +++ b/src/content/docs/br/docs/protocol-reference/transactions/pseudo-transaction-types/emitfailure.mdx @@ -0,0 +1,4 @@ +--- +title: EmitFailure +--- +A DEFINIR \ No newline at end of file diff --git a/src/content/docs/br/docs/protocol-reference/transactions/pseudo-transaction-types/enableamendment.mdx b/src/content/docs/br/docs/protocol-reference/transactions/pseudo-transaction-types/enableamendment.mdx new file mode 100644 index 0000000..3ec0609 --- /dev/null +++ b/src/content/docs/br/docs/protocol-reference/transactions/pseudo-transaction-types/enableamendment.mdx @@ -0,0 +1,38 @@ +--- +title: EnableAmendment +--- +Uma pseudo-transação `EnableAmendment` marca uma mudança no status de uma emenda proposta quando ela: + +* Obtém aprovação de supermaioria dos validadores. +* Perde aprovação de supermaioria. +* É habilitada no protocolo Xahau. + +### Exemplo de JSON + +```json +{ + "Account": "rrrrrrrrrrrrrrrrrrrrrhoLvTp", + "Amendment": "42426C4D4F1009EE67080A9B7965B44656D7714D104A72F9B4369F97ABF044EE", + "Fee": "0", + "LedgerSequence": 21225473, + "Sequence": 0, + "SigningPubKey": "", + "TransactionType": "EnableAmendment" +} +``` + +| Campo | Tipo JSON | \[Tipo Interno]\[] | Descrição | +| ---------------- | --------- | ------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `Amendment` | String | Hash256 | Um identificador único para a emenda. Não se destina a ser um nome legível por humanos. Consulte Emendas para uma lista de emendas conhecidas. | +| `LedgerSequence` | Number | UInt32 | O \[índice de ledger]\[] onde esta pseudo-transação aparece. Isso distingue a pseudo-transação de outras ocorrências da mesma mudança. | + +### Flags de EnableAmendment + +O valor `Flags` da pseudo-transação EnableAmendment indica o status da emenda no momento do ledger que inclui a pseudo-transação. + +Um valor `Flags` de `0` (sem flags) ou um campo `Flags` omitido indica que a emenda foi habilitada e se aplica a todos os ledgers posteriores. Outros valores de `Flags` são os seguintes: + +| Nome do Flag | Valor Hex | Valor Decimal | Descrição | +| ---------------- | ------------ | ------------- | ---------------------------------------------------------------------------------------------------------------------- | +| `tfGotMajority` | `0x00010000` | 65536 | O suporte a esta emenda aumentou para pelo menos 80% dos validadores confiáveis a partir desta versão de ledger. | +| `tfLostMajority` | `0x00020000` | 131072 | O suporte a esta emenda diminuiu para menos de 80% dos validadores confiáveis a partir desta versão de ledger. | diff --git a/src/content/docs/br/docs/protocol-reference/transactions/pseudo-transaction-types/index.mdx b/src/content/docs/br/docs/protocol-reference/transactions/pseudo-transaction-types/index.mdx new file mode 100644 index 0000000..2fb7b7a --- /dev/null +++ b/src/content/docs/br/docs/protocol-reference/transactions/pseudo-transaction-types/index.mdx @@ -0,0 +1,26 @@ +--- +title: Tipos de Pseudo-Transações +--- +Pseudo-transações nunca são enviadas por usuários, nem propagadas pela rede. Em vez disso, um servidor pode optar por injetar pseudo-transações em um ledger proposto diretamente de acordo com regras de protocolo específicas. Se servidores suficientes propuserem exatamente a mesma pseudo-transação, o processo de consenso a aprova, e a pseudo-transação é incluída nos dados de transação daquele ledger. + +### Valores Especiais para Campos Comuns + +Alguns dos \[campos comuns]\[] obrigatórios para transações normais não fazem sentido para pseudo-transações. As pseudo-transações usam os seguintes valores especiais para esses campos comuns: + +| Campo | Tipo JSON | \[Tipo Interno]\[] | Valor | +| --------------- | --------- | ------------------- | ------------------- | +| `Account` | String | AccountID | ACCOUNT_ZERO | +| `Fee` | String | Amount | `0` | +| `Sequence` | Number | UInt32 | `0` | +| `SigningPubKey` | String | Blob | `""` (String vazia) | +| `TxnSignature` | String | Blob | `""` (String vazia) | + +As pseudo-transações usam os seguintes campos comuns normalmente: + +* `TransactionType` +* `Flags` + +| Campo | Tipo JSON | \[Tipo Interno]\[] | Descrição | +| ----------------- | --------- | ------------------- | ------------------------------------------------------------------------------------------------------------------------------ | +| `TransactionType` | String | UInt16 | _(Obrigatório)_ O tipo da transação. | +| `Flags` | Number | UInt32 | _(Opcional)_ Um conjunto de flags de bits para esta transação. O significado de flags específicas varia de acordo com o tipo de transação. | diff --git a/src/content/docs/br/docs/protocol-reference/transactions/pseudo-transaction-types/setfee.mdx b/src/content/docs/br/docs/protocol-reference/transactions/pseudo-transaction-types/setfee.mdx new file mode 100644 index 0000000..5bcb9af --- /dev/null +++ b/src/content/docs/br/docs/protocol-reference/transactions/pseudo-transaction-types/setfee.mdx @@ -0,0 +1,42 @@ +--- +title: SetFee +--- +Uma pseudo-transação `SetFee` marca uma mudança no custo de transação ou nos requisitos de reserva como resultado de Votação de Taxa. + +**Nota:** Você não pode enviar uma pseudo-transação, mas pode encontrar uma ao processar ledgers. + +### Exemplo de JSON + +```json +{ + "Account": "rrrrrrrrrrrrrrrrrrrrrhoLvTp", + "BaseFee": "000000000000000A", + "Fee": "0", + "ReferenceFeeUnits": 10, + "ReserveBase": 20000000, + "ReserveIncrement": 5000000, + "Sequence": 0, + "SigningPubKey": "", + "TransactionType": "SetFee", + "date": 439578860, + "hash": "1C15FEA3E1D50F96B6598607FC773FF1F6E0125F30160144BE0C5CBC52F5151B", + "ledger_index": 3721729, +} +``` + +| Campo | Tipo JSON | \[Tipo Interno]\[] | Descrição | +| ------------------- | ---------------- | ------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| `BaseFee` | String | UInt64 | A cobrança, em drops de XAH, pela transação de referência, em hexadecimal. (Este é o custo de transação antes do escalonamento por carga.) | +| `ReferenceFeeUnits` | Unsigned Integer | UInt32 | O custo, em unidades de taxa, da transação de referência | +| `ReserveBase` | Unsigned Integer | UInt32 | A reserva base, em drops | +| `ReserveIncrement` | Unsigned Integer | UInt32 | A reserva incremental, em drops | +| `LedgerSequence` | Number | UInt32 | _(Omitido para algumas pseudo-transações `SetFee` históricas)_ O índice da versão de ledger onde esta pseudo-transação aparece. Isso distingue a pseudo-transação de outras ocorrências da mesma mudança. | + +Se a _\[emenda XAHFees]\[]_ estiver habilitada, as pseudo-transações `SetFee` usam estes campos em vez disso: + +| Campo | Tipo JSON | \[Tipo Interno]\[] | Descrição | +| ----------------------- | --------- | ------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| `BaseFeeDrops` | String | Amount | A cobrança, em drops de XAH, pela transação de referência. (Este é o custo de transação antes do escalonamento por carga.) | +| `ReserveBaseDrops` | String | Amount | A reserva base, em drops | +| `ReserveIncrementDrops` | String | Amount | A reserva incremental, em drops | +| `LedgerSequence` | Number | UInt32 | _(Omitido para algumas pseudo-transações `SetFee` históricas)_ O índice da versão de ledger onde esta pseudo-transação aparece. Isso distingue a pseudo-transação de outras ocorrências da mesma mudança. | diff --git a/src/content/docs/br/docs/protocol-reference/transactions/pseudo-transaction-types/unlmodify.mdx b/src/content/docs/br/docs/protocol-reference/transactions/pseudo-transaction-types/unlmodify.mdx new file mode 100644 index 0000000..0c583ca --- /dev/null +++ b/src/content/docs/br/docs/protocol-reference/transactions/pseudo-transaction-types/unlmodify.mdx @@ -0,0 +1,30 @@ +--- +title: UNLModify +--- +_(Adicionado pela \[emenda NegativeUNL]\[].)_ + +Uma pseudo-transação `UNLModify` marca uma mudança na UNL Negativa, indicando que um validador confiável ficou offline ou voltou a ficar online. + +**Nota:** Você não pode enviar uma pseudo-transação, mas pode encontrar uma ao processar ledgers. + +### Exemplo de JSON + +```json +{ + "Account": "", + "Fee": "0", + "LedgerSequence": 1600000, + "Sequence": 0, + "SigningPubKey": "", + "TransactionType": "UNLModify", + "UNLModifyDisabling": 1, + "UNLModifyValidator": "ED6629D456285AE3613B285F65BBFF168D695BA3921F309949AFCD2CA7AFEC16FE", +} +``` + +| Nome | Tipo JSON | \[Tipo Interno]\[] | Descrição | +| -------------------- | --------- | ------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `TransactionType` | String | UInt16 | O valor `0x0066`, mapeado para a string `UNLModify`, indica que este objeto é uma pseudo-transação `UNLModify`. | +| `LedgerSequence` | Number | UInt32 | O \[índice de ledger]\[] onde esta pseudo-transação aparece. Isso distingue a pseudo-transação de outras ocorrências da mesma mudança. | +| `UNLModifyDisabling` | Number | UInt8 | Se `1`, esta mudança representa a adição de um validador à UNL Negativa. Se `0`, esta mudança representa a remoção de um validador da UNL Negativa. (Nenhum outro valor é permitido.) | +| `UNLModifyValidator` | String | Blob | O validador a adicionar ou remover, identificado por sua chave pública mestre. | diff --git a/src/content/docs/br/docs/protocol-reference/transactions/pseudo-transaction-types/unlreport.mdx b/src/content/docs/br/docs/protocol-reference/transactions/pseudo-transaction-types/unlreport.mdx new file mode 100644 index 0000000..e1f0803 --- /dev/null +++ b/src/content/docs/br/docs/protocol-reference/transactions/pseudo-transaction-types/unlreport.mdx @@ -0,0 +1,4 @@ +--- +title: UNLReport +--- +A DEFINIR \ No newline at end of file diff --git a/src/content/docs/br/docs/protocol-reference/transactions/transaction-common-fields.mdx b/src/content/docs/br/docs/protocol-reference/transactions/transaction-common-fields.mdx new file mode 100644 index 0000000..5a72c65 --- /dev/null +++ b/src/content/docs/br/docs/protocol-reference/transactions/transaction-common-fields.mdx @@ -0,0 +1,167 @@ +--- +title: Campos Comuns de Transações +--- + +Toda transação tem o mesmo conjunto de campos comuns, além de campos adicionais baseados no tipo de transação. Os nomes dos campos diferenciam maiúsculas de minúsculas. Os campos comuns para todas as transações são: + +| Campo | Tipo JSON | \[Tipo Interno]\[] | Descrição | +| -------------------- | ---------------- | ------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| `Account` | String | AccountID | _(Obrigatório)_ O endereço único da conta que iniciou a transação. | +| `TransactionType` | String | UInt16 | _(Obrigatório)_ O tipo de transação. Os tipos de transação válidos incluem: `Payment`, `OfferCreate`, `TrustSet` e muitos outros. | +| `Fee` | String | Amount | _(Obrigatório; preenchimento automático)_ Valor inteiro de XAH, em drops, a ser destruído como custo pela distribuição desta transação à rede. Alguns tipos de transação têm requisitos mínimos diferentes. Consulte \[Custo de Transação]\[] para detalhes. | +| `Sequence` | Number | UInt32 | _(Obrigatório; preenchimento automático)_ O número de sequência da conta que envia a transação. Uma transação só é válida se o número `Sequence` for exatamente 1 maior que a transação anterior da mesma conta. O caso especial `0` significa que a transação está usando um Ticket em vez disso _(Adicionado pela \[emenda TicketBatch]\[].)_. | +| `AccountTxnID` | String | Hash256 | _(Opcional)_ Valor hash identificando outra transação. Se fornecido, esta transação só é válida se a transação enviada anteriormente pela conta remetente corresponder ao hash fornecido. | +| `Flags` | Number | UInt32 | _(Opcional)_ Conjunto de flags de bits para esta transação. | +| `LastLedgerSequence` | Number | UInt32 | _(Opcional; fortemente recomendado)_ Índice de ledger mais alto em que esta transação pode aparecer. Especificar este campo estabelece um limite superior estrito sobre por quanto tempo a transação pode aguardar para ser validada ou rejeitada. Consulte Envio Confiável de Transações para mais detalhes. | +| `Memos` | Array of Objects | Array | _(Opcional)_ Informações arbitrárias adicionais usadas para identificar esta transação. | +| `NetworkID` | Number | UInt32 | _(Específico da rede)_ O ID de rede da cadeia para a qual esta transação se destina. **DEVE SER OMITIDO** para a Mainnet e algumas redes de teste. **OBRIGATÓRIO** em cadeias cujo ID de rede é 1025 ou superior. | +| `Signers` | Array | Array | _(Opcional)_ Array de objetos que representam uma multi-assinatura que autoriza esta transação. | +| `SourceTag` | Number | UInt32 | _(Opcional)_ Inteiro arbitrário usado para identificar o motivo deste pagamento, ou um remetente em cujo nome esta transação é feita. Convencionalmente, um reembolso deve especificar o `SourceTag` do pagamento inicial como o `DestinationTag` do pagamento de reembolso. | +| `SigningPubKey` | String | Blob | _(Adicionado automaticamente ao assinar)_ Representação hexadecimal da chave pública que corresponde à chave privada usada para assinar esta transação. Se uma string vazia, indica que uma multi-assinatura está presente no campo `Signers` em vez disso. | +| `TicketSequence` | Number | UInt32 | _(Opcional)_ O número de sequência do ticket a usar no lugar de um número `Sequence`. Se fornecido, `Sequence` deve ser `0`. Não pode ser usado com `AccountTxnID`. | +| `TxnSignature` | String | Blob | _(Adicionado automaticamente ao assinar)_ A assinatura que verifica que esta transação se origina da conta que diz ser. | +| `EmitDetails` | Object | Object | Contém detalhes sobre a emissão. Inclui a geração da emissão, o ônus da emissão, o endereço de callback, o hash do hook que emitiu a transação, o nonce da emissão e o ID da transação pai. | +| `HookParameters` | Array | Array | Os parâmetros de hook da transação. | + +\[Removido em: rippled 0.28.0]\[]: O campo `PreviousTxnID` das transações foi substituído pelo campo `AccountTxnID`. Este campo String/Hash256 está presente em algumas transações históricas. Isso não está relacionado ao campo também denominado `PreviousTxnID` em alguns objetos de ledger. + +### AccountTxnID + +O campo `AccountTxnID` permite encadear suas transações, de modo que uma transação atual não seja válida, a menos que a transação anterior enviada pela mesma conta tenha um \[hash de transação]\[hash identificador] específico. + +Ao contrário do campo `PreviousTxnID`, que rastreia a última transação que _modificou_ uma conta (independentemente do remetente), o `AccountTxnID` rastreia a última transação _enviada por_ uma conta. Para usar `AccountTxnID`, você deve primeiro habilitar o flag `asfAccountTxnID`, para que o ledger rastreie o ID da transação anterior da conta. (`PreviousTxnID`, em comparação, é sempre rastreado.) + +Uma situação em que isso é útil é quando você tem um sistema primário para enviar transações e um sistema de backup passivo. Se o sistema de backup passivo ficar desconectado do primário, mas o primário não estiver completamente inativo, e ambos começarem a operar ao mesmo tempo, você poderia ter problemas sérios, como algumas transações sendo enviadas duas vezes e outras não sendo enviadas. Encadear suas transações com `AccountTxnID` garante que, mesmo que ambos os sistemas estejam ativos, apenas um deles possa enviar transações válidas de cada vez. + +O campo `AccountTxnID` não pode ser usado em transações que usam Tickets. Transações que usam `AccountTxnID` não podem ser colocadas na fila de transações. + +### Campos com Preenchimento Automático + +Alguns campos podem ser preenchidos automaticamente antes de uma transação ser assinada, seja por um servidor `xahaud` ou por uma biblioteca cliente. O preenchimento automático de valores requer uma conexão ativa com o Xahau para obter o estado mais recente, portanto não pode ser feito offline. Os detalhes podem variar por biblioteca, mas o preenchimento automático sempre fornece valores adequados para pelo menos os seguintes campos: + +* `Fee` - Preenche automaticamente o \[Custo de Transação]\[] com base na rede. + + **Nota:** Ao usar o \[comando sign]\[] do `xahaud`, você pode limitar o valor máximo possível de preenchimento automático, usando os parâmetros `fee_mult_max` e `fee_mult_div`.) +* `Sequence` - Usa automaticamente o próximo número de sequência para a conta que envia a transação. + +Para um sistema de produção, recomendamos _não_ deixar esses campos serem preenchidos pelo servidor. Por exemplo, se os custos de transação ficarem altos devido a um pico temporário na carga da rede, você pode preferir aguardar a redução do custo antes de enviar algumas transações, em vez de pagar o custo temporariamente alto. + +O campo `Paths` do tipo \[transação Payment]\[] também pode ser preenchido automaticamente. + +### Campo Flags + +O campo `Flags` pode conter várias opções que afetam como uma transação deve se comportar. As opções são representadas como valores binários que podem ser combinados com operações bit a bit OR para definir múltiplos flags de uma vez. + +Para verificar se uma transação tem um determinado flag habilitado, use o operador AND bit a bit no valor do flag e no campo `Flags`. Um resultado zero indica que o flag está desabilitado, e um resultado igual ao valor do flag indica que o flag está habilitado. + +A maioria dos flags só tem significado para um tipo de transação específico. O mesmo valor bit a bit pode ser reutilizado para flags em diferentes tipos de transação, por isso é importante prestar atenção ao campo `TransactionType` ao definir e ler flags. + +Bits que não estão definidos como flags DEVEM ser 0. (A \[emenda fix1543]\[] aplica esta regra em alguns tipos de transação. A maioria dos tipos de transação aplica esta regra por padrão.) + +#### Flags Globais + +O único flag que se aplica globalmente a todas as transações é o seguinte: + +| Nome do Flag | Valor Hex | Valor Decimal | Descrição | +| --------------------- | ------------ | ------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- | +| `tfFullyCanonicalSig` | `0x80000000` | 2147483648 | **DESCONTINUADO** Sem efeito. (Se a \[emenda RequireFullyCanonicalSig]\[] não estiver habilitada, este flag aplica uma assinatura totalmente canônica.) | + +#### Intervalos de Flags + +O campo `Flags` de uma transação pode conter flags que se aplicam em diferentes níveis ou contextos. Flags para cada contexto são limitados aos seguintes intervalos: + +| Nome do Intervalo | Máscara de Bits | Descrição | +| ------------------- | --------------- | -------------------------------------------------------------------------------------------------- | +| Flags Universais | `0xff000000` | Flags que se aplicam igualmente a todos os tipos de transação. | +| Flags Baseados em Tipo | `0x00ff0000` | Flags com diferentes significados dependendo do tipo de transação que os usa. | +| Flags Reservados | `0x0000ffff` | Flags que não estão atualmente definidos. Uma transação só é válida se esses flags estiverem desabilitados. | + +**Nota:** O tipo de \[transação AccountSet]\[] tem seus próprios flags não bit a bit, que servem a um propósito semelhante ao dos flags baseados em tipo. Objetos de ledger também têm um campo `Flags` com diferentes definições de flag bit a bit. + +### Campo Memos + +O campo `Memos` inclui dados de mensagens arbitrárias com a transação. É apresentado como um array de objetos. Cada objeto tem apenas um campo, `Memo`, que por sua vez contém outro objeto com _um ou mais_ dos seguintes campos: + +| Campo | Tipo | \[Tipo Interno]\[] | Descrição | +| ------------ | ------ | ------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `MemoData` | String | Blob | Valor hexadecimal arbitrário, convencionalmente contendo o conteúdo do memo. | +| `MemoFormat` | String | Blob | Valor hexadecimal representando caracteres permitidos em URLs. Convencionalmente contendo informações sobre como o memo está codificado, por exemplo como um [tipo MIME](http://www.iana.org/assignments/media-types/media-types.xhtml). | +| `MemoType` | String | Blob | Valor hexadecimal representando caracteres permitidos em URLs. Convencionalmente, uma relação única (de acordo com [RFC 5988](http://tools.ietf.org/html/rfc5988#section-4)) que define o formato deste memo. | + +Os campos `MemoType` e `MemoFormat` devem consistir apenas nos seguintes caracteres: `ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789-._~:/?#[]@!$&'()*+,;=%` + +O campo `Memos` é limitado a no máximo 1 KB de tamanho (quando serializado em formato binário). + +**Custo de Transação:** Transações com um campo `Memos` incorrem em um custo adicional baseado no tamanho dos memos. O custo aumenta proporcionalmente com o tamanho total de todos os memos na transação. + +Exemplo de uma transação com um campo Memos: + +```json +{ + "TransactionType": "Payment", + "Account": "rMmTCjGFRWPz8S2zAUUoNVSQHxtRQD4eCx", + "Destination": "r3kmLJN5D28dHuH8vZNUZpMC43pEHpaocV", + "Memos": [ + { + "Memo": { + "MemoType": "687474703a2f2f6578616d706c652e636f6d2f6d656d6f2f67656e65726963", + "MemoData": "72656e74" + } + } + ], + "Amount": "1" +} +``` + +### Campo NetworkID + +\[Novo em: rippled 1.11.0]\[] + +O campo `NetworkID` é uma proteção contra ataques de repetição de transações em "cadeia cruzada", impedindo que a mesma transação seja copiada e executada em uma rede paralela para a qual não foi destinada. Para compatibilidade com cadeias existentes, o campo `NetworkID` deve ser omitido em qualquer rede com um ID de rede de 1024 ou menos, mas deve ser incluído em qualquer rede com um ID de rede de 1025 ou mais. A tabela a seguir mostra o status e os valores para várias redes conhecidas: + +| Rede | ID | Campo `NetworkID` | +| --------------------------------- | ----- | ------------------------------------------------------- | +| Mainnet | 0 | Não permitido | +| Testnet | 1 | Não permitido | +| Devnet | 2 | Não permitido | +| AMM Devnet | 25 | Não permitido | +| Sidechains Devnet Locking Chain | 2551 | Não permitido, mas se tornará obrigatório após atualização | +| Sidechains Devnet Issuing Chain | 2552 | Não permitido, mas se tornará obrigatório após atualização | +| Xahau Testnet | 21338 | Obrigatório | +| Xahau Mainnet | 21337 | Obrigatório | + +### Campo Signers + +O campo `Signers` contém uma multi-assinatura, que possui assinaturas de até 8 pares de chaves, que juntos devem autorizar a transação. A lista `Signers` é um array de objetos, cada um com um campo, `Signer`. O campo `Signer` tem os seguintes campos aninhados: + +| Campo | Tipo | \[Tipo Interno]\[] | Descrição | +| --------------- | ------ | ------------------- | -------------------------------------------------------------------------------- | +| `Account` | String | AccountID | O endereço associado a esta assinatura, conforme aparece na lista de signatários. | +| `TxnSignature` | String | Blob | Uma assinatura para esta transação, verificável usando a `SigningPubKey`. | +| `SigningPubKey` | String | Blob | A chave pública usada para criar esta assinatura. | + +Como a verificação de assinatura é uma tarefa computacionalmente intensiva, transações multi-assinadas custam XAH adicional para serem retransmitidas à rede. Cada assinatura incluída na multi-assinatura aumenta o \[custo de transação]\[] exigido para a transação. + +### Campos de EmitDetails + +Um objeto `EmitDetails` tem os seguintes campos: + +| Campo | Tipo JSON | \[Tipo Interno]\[] | Obrigatório? | Descrição | +| ----------------- | --------- | ------------------- | ------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `EmitGeneration` | Number | UInt32 | Sim | Este campo rastreia uma cadeia de transações emitidas que por sua vez causam outras transações a serem emitidas. | +| `EmitBurden` | String | UInt64 | Sim | Este campo é uma heurística para detectar forkbombs. As taxas são baseadas no ônus e aumentarão exponencialmente quando uma reação em cadeia for iniciada para evitar que a rede seja sobrecarregada por transações emitidas auto-reforçantes. | +| `EmitParentTxnID` | String | Hash256 | Sim | A Execução de Hook que emitiu a transação está conectada à Transação de Origem. Portanto, este campo é sempre necessário para o rastreamento eficiente do comportamento. | +| `EmitNonce` | String | Hash256 | Sim | Transações emitidas seriam idênticas com os mesmos campos e, portanto, teriam hashes de transação idênticos se um nonce não fosse usado. No entanto, cada nó na rede precisa concordar com o nonce, então uma API Hook especial para produzir um nonce determinístico é disponibilizada. | +| `EmitCallback` | String | AccountID | Não | Este campo é usado pelo xahld quando precisa iniciar um callback, para saber qual Hook e conta iniciar o callback. Callbacks acontecem quando uma transação emitida é aceita em um ledger. | +| `EmitHookHash` | String | Hash256 | Sim | O SHA512H do Hook no momento em que foi executado. | + +### Parâmetros de Hook + +O campo `HookParameters` é um array de objetos que especificam os parâmetros do hook. Cada objeto de parâmetro tem os seguintes campos: + +| Campo | Tipo JSON | Tipo Interno | Descrição | +| ------- | --------- | ------------- | ---------------------------- | +| `Name` | String | Blob | O nome do parâmetro. | +| `Value` | String | Blob | O valor do parâmetro. | + +**Custo de Transação:** Transações com um campo `HookParameters` incorrem em um custo adicional baseado no tamanho dos parâmetros de hook. O custo aumenta proporcionalmente com o tamanho total de todos os parâmetros na transação. diff --git a/src/content/docs/br/docs/protocol-reference/transactions/transaction-metadata.mdx b/src/content/docs/br/docs/protocol-reference/transactions/transaction-metadata.mdx new file mode 100644 index 0000000..edab906 --- /dev/null +++ b/src/content/docs/br/docs/protocol-reference/transactions/transaction-metadata.mdx @@ -0,0 +1,175 @@ +--- +title: Metadados de Transação +--- +Os metadados de transação são uma seção de dados adicionada a uma transação após o seu processamento. Qualquer transação que seja incluída em um ledger tem metadados, independentemente de ter sido bem-sucedida ou não. Os metadados de transação descrevem o resultado da transação em detalhes. + +:::caution +As mudanças descritas nos metadados de transação só são definitivas se a transação estiver em uma versão de ledger validada. +::: + +
+ +Exemplo de Metadados + +O seguinte objeto JSON mostra os metadados de [um pagamento complexo entre moedas](https://xrpcharts.ripple.com/#/transactions/8C55AFC2A2AA42B5CE624AEECDB3ACFDD1E5379D4E5BF74A8460C5E97EF8706B): + +```json +{ + "AffectedNodes": [ + { + "ModifiedNode": { + "FinalFields": { + "Account": "r9ZoLsJHzMMJLpvsViWQ4Jgx17N8cz1997", + "Balance": "77349986", + "Flags": 0, + "OwnerCount": 2, + "Sequence": 9 + }, + "LedgerEntryType": "AccountRoot", + "LedgerIndex": "1E7E658C2D3DF91EFAE5A12573284AD6F526B8F64DD12F013C6F889EF45BEA97", + "PreviousFields": { + "OwnerCount": 3 + }, + "PreviousTxnID": "55C11248ACEFC2EFD59755BF88867783AC18EA078517108F942069C2FBE4CF5C", + "PreviousTxnLgrSeq": 35707468 + } + }, + { + "ModifiedNode": { + "FinalFields": { + "Balance": { + "currency": "USD", + "issuer": "rrrrrrrrrrrrrrrrrrrrBZbvji", + "value": "2298.927882138068" + }, + "Flags": 1114112, + "HighLimit": { + "currency": "USD", + "issuer": "rLEsXccBGNR3UPuPu2hUXPjziKC3qKSBun", + "value": "0" + }, + "HighNode": "000000000000006B", + "LowLimit": { + "currency": "USD", + "issuer": "rpvvAvaZ7TXHkNLM8UJwCTU6yBU2jDTJ1P", + "value": "1000000000" + }, + "LowNode": "0000000000000007" + }, + "LedgerEntryType": "RippleState", + "LedgerIndex": "220DDA7164F3F41F3C5223FA3125D4CD368EBB4FB954B5FBFFB6D1EA6DACDD5E", + "PreviousFields": { + "Balance": { + "currency": "USD", + "issuer": "rrrrrrrrrrrrrrrrrrrrBZbvji", + "value": "2297.927882138068" + } + }, + "PreviousTxnID": "1DB2F9C67C3F42F7B8AB02BA2264254A78A201EC8A9974A1CACEFD51545B1263", + "PreviousTxnLgrSeq": 43081739 + } + }, + { + "DeletedNode": { + "FinalFields": { + "Account": "r9ZoLsJHzMMJLpvsViWQ4Jgx17N8cz1997", + "BookDirectory": "A6D5D1C1CC92D56FDDFD4434FB10BD31F63EB991DA3C756653071AFD498D0000", + "BookNode": "0000000000000000", + "Flags": 0, + "OwnerNode": "0000000000000000", + "PreviousTxnID": "DB028A461E98B0398CAD65F2871B381A6D0B9A21662CA5B033438D83C518C0F2", + "PreviousTxnLgrSeq": 35686129, + "Sequence": 7, + "TakerGets": { + "currency": "EUR", + "issuer": "rhub8VRN55s94qWKDv6jmDy1pUykJzF3wq", + "value": "2.5" + }, + "TakerPays": { + "currency": "ETH", + "issuer": "rcA8X3TVMST1n3CJeAdGk1RdRCHii7N2h", + "value": "0.05" + } + }, + "LedgerEntryType": "Offer", + "LedgerIndex": "6AA7E5121FEB456F0A899E3D6F25D62ABB408BB67B91C9270E13714401ED72B5" + } + } + ], + "DeliveredAmount": { + "currency": "GCB", + "issuer": "rHaans8PtgwbacHvXAL3u6TG28gTAtCwr8", + "value": "2.788706" + }, + "TransactionIndex": 38, + "TransactionResult": "tesSUCCESS", + "delivered_amount": { + "currency": "GCB", + "issuer": "rHaans8PtgwbacHvXAL3u6TG28gTAtCwr8", + "value": "2.788706" + } +} +``` + + + +
+ +### AffectedNodes + +O array `AffectedNodes` contém uma lista completa dos objetos no ledger que esta transação modificou de alguma forma. Cada entrada neste array é um objeto com um campo de nível superior indicando qual tipo é: + +* `CreatedNode` indica que a transação criou um novo objeto no ledger. +* `DeletedNode` indica que a transação removeu um objeto do ledger. +* `ModifiedNode` indica que a transação modificou um objeto existente no ledger. + +O valor de cada um desses campos é um objeto JSON que descreve as alterações feitas no objeto de ledger. + +#### Campos de CreatedNode + +Um objeto `CreatedNode` contém os seguintes campos: + +| Campo | Valor | Descrição | +| ----------------- | ------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| `LedgerEntryType` | String | O tipo de objeto de ledger que foi criado. | +| `LedgerIndex` | String - \[Hash]\[] | O ID deste objeto de ledger na árvore de estado do ledger. **Nota:** Isso **não é o mesmo** que um índice de ledger, mesmo que o nome do campo seja similar. | +| `NewFields` | Object | Os campos de conteúdo do objeto de ledger recém-criado. Quais campos estão presentes depende do tipo de objeto de ledger que foi criado. | + +#### Campos de DeletedNode + +Um objeto `DeletedNode` contém os seguintes campos: + +| Campo | Valor | Descrição | +| ----------------- | ------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| `LedgerEntryType` | String | O tipo de objeto de ledger que foi excluído. | +| `LedgerIndex` | String - \[Hash]\[] | O ID deste objeto de ledger na árvore de estado do ledger. **Nota:** Isso **não é o mesmo** que um índice de ledger, mesmo que o nome do campo seja similar. | +| `FinalFields` | Object | Os campos de conteúdo do objeto de ledger imediatamente antes de ser excluído. Quais campos estão presentes depende do tipo de objeto de ledger que foi criado. | + +#### Campos de ModifiedNode + +Um objeto `ModifiedNode` contém os seguintes campos: + +| Campo | Valor | Descrição | +| ------------------- | --------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `LedgerEntryType` | String | O tipo de objeto de ledger que foi modificado. | +| `LedgerIndex` | String - \[Hash]\[] | O ID deste objeto de ledger na árvore de estado do ledger. **Nota:** Isso **não é o mesmo** que um índice de ledger, mesmo que o nome do campo seja similar. | +| `FinalFields` | Object | Os campos de conteúdo do objeto de ledger após a aplicação de quaisquer alterações desta transação. Quais campos estão presentes depende do tipo de objeto de ledger. Isso omite os campos `PreviousTxnID` e `PreviousTxnLgrSeq`, mesmo que a maioria dos tipos de objetos de ledger os tenha. | +| `PreviousFields` | Object | Os valores anteriores de todos os campos do objeto que foram alterados como resultado desta transação. Se a transação _apenas adicionou_ campos ao objeto, este campo é um objeto vazio. | +| `PreviousTxnID` | String - \[Hash]\[] | _(Pode ser omitido)_ O \[hash identificador]\[] da transação anterior que modificou este objeto de ledger. Omitido para tipos de objetos de ledger que não têm um campo `PreviousTxnID`. | +| `PreviousTxnLgrSeq` | Number - \[Ledger Index]\[] | _(Pode ser omitido)_ O \[Índice de Ledger]\[] da versão de ledger que contém a transação anterior que modificou este objeto de ledger. Omitido para tipos de objetos de ledger que não têm um campo `PreviousTxnLgrSeq`. | + +**Nota:** Se o objeto de ledger modificado tiver campos `PreviousTxnID` e `PreviousTxnLgrSeq`, a transação sempre os atualiza com o hash identificador da própria transação e o índice da versão de ledger que incluiu a transação, mas os novos valores desses campos não estão listados em `FinalFields` do objeto `ModifiedNode`, e seus valores anteriores estão listados no nível superior do objeto `ModifiedNode` em vez de no objeto `PreviousFields` aninhado. + +### delivered_amount + +O `Amount` de uma \[transação Payment]\[] indica o valor a entregar ao `Destination`, portanto, se a transação foi bem-sucedida, o destino recebeu esse valor -- **exceto se a transação foi um pagamento parcial**. Em vez de escolher se deve ou não confiar no campo `Amount`, você deve usar o campo `delivered_amount` dos metadados para ver quanto realmente chegou ao seu destino. + +O servidor `rippled` fornece um campo `delivered_amount` nos metadados de transação JSON para todas as transações de Pagamento bem-sucedidas. Este campo é formatado como um valor de moeda normal. No entanto, o valor entregue não está disponível para transações que atendam aos seguintes critérios: + +* É um pagamento parcial + +Se a transação for um pagamento parcial, `delivered_amount` contém o valor de string `unavailable` em vez de um valor real. Se isso acontecer, você só pode descobrir o valor realmente entregue lendo os `AffectedNodes` nos metadados da transação. + +**Nota:** O campo `delivered_amount` é gerado sob demanda para a solicitação e não está incluído no formato binário para metadados de transação, nem é usado ao calcular o hash dos metadados da transação. + +Consulte também: Pagamentos Parciais diff --git a/src/content/docs/br/docs/protocol-reference/transactions/transaction-results/index.mdx b/src/content/docs/br/docs/protocol-reference/transactions/transaction-results/index.mdx new file mode 100644 index 0000000..27e13bb --- /dev/null +++ b/src/content/docs/br/docs/protocol-reference/transactions/transaction-results/index.mdx @@ -0,0 +1,45 @@ +--- +title: Resultados de Transações +--- +[\[Fonte\]](https://github.com/ripple/rippled/blob/master/src/ripple/protocol/TER.h) + +O servidor `rippled` resume os resultados de transações com códigos de resultado, que aparecem em campos como `engine_result` e `meta.TransactionResult`. Esses códigos são agrupados em várias categorias com diferentes prefixos: + +| Categoria | Prefixo | Descrição | +| ---------------------------- | ------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Apenas custo reivindicado | `tec` | A transação não atingiu seu propósito pretendido, mas o custo da transação foi destruído. Este resultado só é definitivo em um ledger validado. | +| Falha | `tef` | A transação não pode ser aplicada ao ledger atual (em andamento) do servidor ou a qualquer ledger posterior. Pode já ter sido aplicada, ou a condição do ledger torna impossível aplicá-la no futuro. | +| Erro local | `tel` | O servidor `rippled` teve um erro devido a condições locais, como alta carga. Você pode obter uma resposta diferente se reenviar para um servidor diferente ou em um momento diferente. | +| Transação malformada | `tem` | A transação não era válida, devido a sintaxe incorreta, opções conflitantes, uma assinatura inválida ou outra coisa. | +| Tentar novamente | `ter` | A transação não pôde ser aplicada, mas pode ser aplicada com sucesso em um ledger futuro. | +| Sucesso | `tes` | (Não é um erro) A transação foi bem-sucedida. Este resultado só é definitivo em um ledger validado. | + +O servidor `rippled` repete automaticamente as transações com falha. É importante não presumir que uma transação falhou completamente com base em um resultado de falha provisório. Uma transação pode ter sucesso posteriormente, a menos que seu sucesso ou falha seja definitivo. + +**Aviso:** Os códigos de resultado provisórios das transações podem diferir dos seus resultados finais. Transações que provisoriamente tiveram sucesso podem eventualmente falhar, e transações que provisoriamente falharam podem eventualmente ter sucesso. Transações que provisoriamente falharam também podem eventualmente falhar com um código diferente. Consulte a finalidade dos resultados para saber quando o resultado de uma transação é definitivo. + +A distinção entre um erro local (`tel`) e uma transação malformada (`tem`) é uma questão de regras de nível de protocolo. Por exemplo, o protocolo não define limite no número máximo de caminhos que podem ser incluídos em uma transação. No entanto, um servidor pode definir um limite finito de caminhos que pode processar. Se dois servidores diferentes forem configurados de forma diferente, então um deles pode retornar um erro `tel` para uma transação com muitos caminhos, enquanto o outro servidor pode processar a transação com sucesso. Se servidores suficientes puderem processar a transação para que ela sobreviva ao consenso, ela ainda pode ser incluída em um ledger validado. + +Em contraste, um erro `tem` implica que nenhum servidor pode aplicar a transação, independentemente das configurações. Ou a transação viola as regras do protocolo, é inaceitavelmente ambígua ou é completamente sem sentido. A única maneira de uma transação malformada se tornar válida é por meio de mudanças no protocolo; por exemplo, se um novo recurso for adotado, então transações usando esse recurso poderiam ser consideradas malformadas por servidores que executam software mais antigo, anterior a esse recurso. + +### Resposta Imediata + +A resposta do \[método submit]\[] contém um resultado provisório do servidor `rippled` indicando o que aconteceu durante o processamento local da transação. + +A resposta de `submit` contém os seguintes campos: + +| Campo | Valor | Descrição | +| ----------------------- | -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `engine_result` | String | Um código indicando o resultado da transação, como `tecPATH_DRY`. | +| `engine_result_code` | Signed Integer | Um número que corresponde ao `engine_result`. Os valores exatos estão sujeitos a alterações sem aviso prévio. | +| `engine_result_message` | String | Uma mensagem legível por humanos explicando o que aconteceu. Esta mensagem é destinada aos desenvolvedores para diagnosticar problemas e está sujeita a mudanças sem aviso. | + +Se nada deu errado ao enviar e aplicar a transação localmente, a resposta se parece com isso: + +```js + "engine_result": "tesSUCCESS", + "engine_result_code": 0, + "engine_result_message": "The transaction was applied. Only final in a validated ledger." +``` + +**Nota:** Um resultado bem-sucedido neste estágio não indica que a transação teve completamente sucesso; apenas que foi aplicada com sucesso à versão provisória do ledger mantida pelo servidor local. Resultados com falha neste estágio também são provisórios e podem mudar. Consulte Finalidade dos Resultados para obter detalhes. diff --git a/src/content/docs/br/docs/protocol-reference/transactions/transaction-results/tec-codes.mdx b/src/content/docs/br/docs/protocol-reference/transactions/transaction-results/tec-codes.mdx new file mode 100644 index 0000000..828e65e --- /dev/null +++ b/src/content/docs/br/docs/protocol-reference/transactions/transaction-results/tec-codes.mdx @@ -0,0 +1,59 @@ +--- +title: Códigos TEC +--- +Esses códigos indicam que a transação falhou, mas foi aplicada a um ledger para aplicar o custo da transação. Eles têm valores numéricos na faixa de 100 a 199. Recomenda-se usar o código de texto, não o valor numérico. + +Transações com códigos `tec` destroem o XAH pago como custo de transação e consomem um número de sequência. Na maior parte, as transações não tomam nenhuma outra ação, mas há algumas exceções. Por exemplo, uma transação que resulta em `tecOVERSIZE` ainda limpa algumas ofertas não financiadas. Sempre observe os metadados da transação para ver precisamente o que uma transação fez. + +**Cuidado:** Uma transação que falhou provisoriamente com um código `tec` ainda pode ter sucesso ou falhar com um código diferente após ser reaplicada. O resultado é definitivo quando aparece em uma versão de ledger validada. Para mais informações, consulte Finalidade dos Resultados e Envio Confiável de Transações. + +| Código | Valor | Explicação | +| ---------------------------------- | ----- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `tecCANT_ACCEPT_OWN_NFTOKEN_OFFER` | 157 | A transação tentou aceitar uma oferta colocada pela mesma conta para comprar ou vender um token não fungível. _(Adicionado pela \[emenda NonFungibleTokensV1_1]\[].)_ | +| `tecCLAIM` | 100 | Falha não especificada, com custo de transação destruído. | +| `tecCRYPTOCONDITION_ERROR` | 146 | Esta transação \[EscrowCreate]\[] ou \[EscrowFinish]\[] continha uma crypto-condição malformada ou incompatível. | +| `tecDIR_FULL` | 121 | A transação tentou adicionar um objeto (como uma linha de confiança, Cheque, Escrow ou Canal de Pagamento) ao diretório do proprietário de uma conta, mas essa conta não pode possuir mais objetos no ledger. | +| `tecDUPLICATE` | 149 | A transação tentou criar um objeto (como uma autorização \[DepositPreauth]\[]) que já existe. | +| `tecDST_TAG_NEEDED` | 143 | A \[transação Payment]\[] omitiu uma tag de destino, mas a conta de destino tem o flag `lsfRequireDestTag` habilitado. | +| `tecEXPIRED` | 148 | A transação tentou criar um objeto (como uma Oferta ou um Cheque) cujo tempo de Expiração fornecido já passou. | +| `tecFAILED_PROCESSING` | 105 | Um erro não especificado ocorreu ao processar a transação. | +| `tecFROZEN` | 137 | A \[transação OfferCreate]\[] falhou porque um ou ambos os ativos envolvidos estão sujeitos a um congelamento global. | +| `tecHAS_OBLIGATIONS` | 151 | A \[transação AccountDelete]\[] falhou porque a conta a ser excluída possui objetos que não podem ser excluídos. Consulte Exclusão de Contas para detalhes. | +| `tecINSUF_RESERVE_LINE` | 122 | A transação falhou porque a conta remetente não tem XAH suficiente para criar uma nova linha de confiança. (Consulte: Reservas) Este erro ocorre quando a contraparte já tem uma linha de confiança em estado não padrão para a conta remetente para a mesma moeda. (Consulte `tecNO_LINE_INSUF_RESERVE` para o outro caso.) | +| `tecINSUF_RESERVE_OFFER` | 123 | A transação falhou porque a conta remetente não tem XAH suficiente para criar uma nova Oferta. (Consulte: Reservas) | +| `tecINSUFF_FEE` | 136 | A transação falhou porque a conta remetente não tem XAH suficiente para pagar o custo de transação que especificou. (Neste caso, o processamento da transação destrói todo o XAH do remetente, mesmo que essa quantidade seja menor do que o custo de transação especificado.) Este resultado só ocorre se o saldo da conta diminuir _após_ esta transação ter sido distribuída para uma rede suficiente para ser incluída em um conjunto de consenso. | +| `tecINSUFFICIENT_FUNDS` | 158 | Uma das contas envolvidas não detém ativos necessários suficientes. _(Adicionado pela \[emenda NonFungibleTokensV1_1]\[].)_ | +| `tecINSUFFICIENT_PAYMENT` | 161 | O valor especificado não é suficiente para pagar todas as taxas envolvidas na transação. Por exemplo, ao negociar um token não fungível, o valor de compra pode não ser suficiente para pagar tanto a taxa do corretor quanto o valor de venda. _(Adicionado pela \[emenda NonFungibleTokensV1_1]\[].)_ | +| `tecINSUFFICIENT_RESERVE` | 141 | A transação aumentaria o requisito de reserva acima do saldo da conta remetente. \[SignerListSet]\[], \[PaymentChannelCreate]\[], \[PaymentChannelFund]\[] e \[EscrowCreate]\[] podem retornar este código de erro. Consulte Listas de Signatários e Reservas para mais informações. | +| `tecINTERNAL` | 144 | Erro interno não especificado, com custo de transação aplicado. Este código de erro normalmente não deve ser retornado. Se você puder reproduzir este erro, por favor [reporte um problema](https://github.com/ripple/rippled/issues). | +| `tecINVARIANT_FAILED` | 147 | Uma verificação de invariante falhou ao tentar executar esta transação. Adicionado pela \[emenda EnforceInvariants]\[]. Se você puder reproduzir este erro, por favor [reporte um problema](https://github.com/ripple/rippled/issues). | +| `tecKILLED` | 150 | A \[transação OfferCreate]\[] especificou o flag `tfFillOrKill` e não pôde ser preenchida, portanto foi cancelada. _(Adicionado pela \[emenda fix1578]\[].)_ | +| `tecMAX_SEQUENCE_REACHED` | 153 | Um campo de número de sequência já está em seu máximo. Isso inclui o campo `MintedNFTokens`. _(Adicionado pela \[emenda NonFungibleTokensV1_1]\[].)_ | +| `tecNEED_MASTER_KEY` | 142 | Esta transação tentou causar mudanças que requerem a chave mestre, como desabilitar a chave mestre ou renunciar à capacidade de congelar saldos. | +| `tecNFTOKEN_BUY_SELL_MISMATCH` | 155 | A \[transação NFTokenAcceptOffer]\[] tentou combinar ofertas incompatíveis para comprar e vender um token não fungível. _(Adicionado pela \[emenda NonFungibleTokensV1_1]\[].)_ | +| `tecNFTOKEN_OFFER_TYPE_MISMATCH` | 156 | Uma ou mais das ofertas especificadas na transação não era do tipo correto de oferta. _(Adicionado pela \[emenda NonFungibleTokensV1_1]\[].)_ | +| `tecNO_ALTERNATIVE_KEY` | 130 | A transação tentou remover o único método disponível de autorizar transações. Pode ser uma \[transação SetRegularKey]\[] para remover a chave regular, uma \[transação SignerListSet]\[] para excluir uma SignerList, ou uma \[transação AccountSet]\[] para desabilitar a chave mestre. | +| `tecNO_AUTH` | 134 | A transação falhou porque precisaria adicionar um saldo em uma linha de confiança a uma conta com o flag `lsfRequireAuth` habilitado, e essa linha de confiança não foi autorizada. Se a linha de confiança não existir, `tecNO_LINE` ocorre em vez disso. | +| `tecNO_DST` | 124 | A conta no lado receptor da transação não existe. Isso inclui tipos de transação Payment e TrustSet. (Poderia ser criada se recebesse XAH suficiente.) | +| `tecNO_DST_INSUF_NATIVE` | 125 | A conta no lado receptor da transação não existe, e a transação não está enviando XAH suficiente para criá-la. | +| `tecNO_ENTRY` | 140 | A transação tentou modificar um objeto de ledger, como um Cheque, Canal de Pagamento ou Pré-autorização de Depósito, mas o objeto especificado não existe. | +| `tecNO_ISSUER` | 133 | A conta especificada no campo `issuer` de um valor de moeda não existe. | +| `tecNO_LINE` | 135 | O campo `TakerPays` da \[transação OfferCreate]\[] especifica um ativo cujo emissor tem `lsfRequireAuth` habilitado, e a conta que faz a oferta não tem uma linha de confiança para esse ativo. | +| `tecNO_LINE_INSUF_RESERVE` | 126 | A transação falhou porque a conta remetente não tem XAH suficiente para criar uma nova linha de confiança. (Consulte: Reservas) Este erro ocorre quando a contraparte não tem uma linha de confiança para esta conta para a mesma moeda. | +| `tecNO_LINE_REDUNDANT` | 127 | A transação falhou porque tentou definir uma linha de confiança para seu estado padrão, mas a linha de confiança não existia. | +| `tecNO_PERMISSION` | 139 | O remetente não tem permissão para fazer esta operação. Por exemplo, a \[transação EscrowFinish]\[] tentou liberar um pagamento retido antes de seu tempo `FinishAfter`, alguém tentou usar \[PaymentChannelFund]\[] em um canal que o remetente não possui, ou um \[Pagamento]\[] tentou entregar fundos a uma conta com o flag "DepositAuth" habilitado. | +| `tecNO_REGULAR_KEY` | 131 | A \[transação AccountSet]\[] tentou desabilitar a chave mestre, mas a conta não tem outra forma de autorizar transações. | +| `tecNO_SUITABLE_NFTOKEN_PAGE` | 154 | A transação tentou cunhar ou adquirir um token não fungível, mas a conta que recebe o `NFToken` não tem uma página de diretório que possa contê-lo. _(Adicionado pela \[emenda NonFungibleTokensV1_1]\[].)_ | +| `tecNO_TARGET` | 138 | A transação referenciou um objeto de ledger Escrow ou PayChannel que não existe, seja porque nunca existiu ou já foi excluído. | +| `tecOBJECT_NOT_FOUND` | 160 | Um dos objetos especificados por esta transação não existia no ledger. _(Adicionado pela \[emenda NonFungibleTokensV1_1]\[].)_ | +| `tecOVERSIZE` | 145 | Esta transação não pôde ser processada porque o servidor criou uma quantidade excessivamente grande de metadados ao tentar aplicar a transação. | +| `tecOWNERS` | 132 | A transação não pode ter sucesso porque o remetente já possui objetos no ledger. Por exemplo, uma conta não pode habilitar o flag `lsfRequireAuth` se tiver linhas de confiança ou ofertas disponíveis. | +| `tecPATH_DRY` | 128 | A transação falhou porque os caminhos fornecidos não tinham liquidez suficiente para enviar nada. Isso pode significar que as contas de origem e destino não estão vinculadas por linhas de confiança. | +| `tecPATH_PARTIAL` | 101 | A transação falhou porque os caminhos fornecidos não tinham liquidez suficiente para enviar o valor total. | +| `tecTOO_SOON` | 152 | A \[transação AccountDelete]\[] falhou porque a conta a ser excluída tinha um número `Sequence` muito alto. O índice do ledger atual deve ser pelo menos 256 maior do que o número de sequência da conta. | +| `tecUNFUNDED` | 129 | A transação falhou porque a conta não tem XAH suficiente para pagar o valor na transação _e_ satisfazer a reserva adicional necessária para executar esta transação. | +| `tecUNFUNDED_ADD` | 102 | **DESCONTINUADO.** | +| `tecUNFUNDED_PAYMENT` | 104 | A transação falhou porque a conta remetente está tentando enviar mais XAH do que possui, sem contar a reserva. | +| `tecUNFUNDED_OFFER` | 103 | A \[transação OfferCreate]\[] falhou porque a conta que cria a oferta não tem nenhuma da moeda `TakerGets`. | +| `tecREQUIRES_FLAG` | 169 | A \[transação SetHook]\[] falhou devido a uma combinação incorreta de Flag e Campo. | +| `tecPRECISION_LOSS` | 170 | A transação falhou porque o resultado terminaria com perda significativa de precisão. | diff --git a/src/content/docs/br/docs/protocol-reference/transactions/transaction-results/tef-codes.mdx b/src/content/docs/br/docs/protocol-reference/transactions/transaction-results/tef-codes.mdx new file mode 100644 index 0000000..372af7c --- /dev/null +++ b/src/content/docs/br/docs/protocol-reference/transactions/transaction-results/tef-codes.mdx @@ -0,0 +1,32 @@ +--- +title: Códigos TEF +--- +Esses códigos indicam que a transação falhou e não foi incluída em um ledger, mas a transação poderia ter tido sucesso em algum ledger teórico. Normalmente isso significa que a transação não pode mais ter sucesso em qualquer ledger futuro. Eles têm valores numéricos na faixa de -199 a -100. O código exato para qualquer erro específico está sujeito a alterações, portanto não dependa dele. + +**Cuidado:** Transações com códigos `tef` não são aplicadas a ledgers e não podem causar nenhuma mudança no estado do Xahau. No entanto, uma transação que falhou provisoriamente ainda pode ter sucesso ou falhar com um código diferente após ser reaplicada. Para mais informações, consulte Finalidade dos Resultados e Envio Confiável de Transações. + +| Código | Explicação | +| -------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| `tefALREADY` | A mesma transação exata já foi aplicada. | +| `tefBAD_ADD_AUTH` | **DESCONTINUADO.** | +| `tefBAD_AUTH` | A chave usada para assinar esta conta não está autorizada a modificar esta conta. (Poderia ser autorizada se a conta tivesse a mesma chave definida como Chave Regular.) | +| `tefBAD_AUTH_MASTER` | A assinatura única fornecida para autorizar esta transação não corresponde à chave mestre, mas nenhuma chave regular está associada a este endereço. | +| `tefBAD_LEDGER` | Ao processar a transação, o ledger foi descoberto em um estado inesperado. Se você puder reproduzir este erro, por favor [reporte um problema](https://github.com/ripple/rippled/issues) para que seja corrigido. | +| `tefBAD_QUORUM` | A transação foi multi-assinada, mas os pesos totais de todas as assinaturas incluídas não atingiram o quorum. | +| `tefBAD_SIGNATURE` | A transação foi multi-assinada, mas continha uma assinatura para um endereço que não faz parte de uma SignerList associada à conta remetente. | +| `tefCREATED` | **DESCONTINUADO.** | +| `tefEXCEPTION` | Ao processar a transação, o servidor entrou em um estado inesperado. Isso pode ser causado por entradas inesperadas, por exemplo se os dados binários da transação estiverem grosseiramente malformados. Se você puder reproduzir este erro, por favor [reporte um problema](https://github.com/ripple/rippled/issues). | +| `tefFAILURE` | Falha não especificada ao aplicar a transação. | +| `tefINTERNAL` | Ao tentar aplicar a transação, o servidor entrou em um estado inesperado. Se você puder reproduzir este erro, por favor [reporte um problema](https://github.com/ripple/rippled/issues). | +| `tefINVARIANT_FAILED` | Uma verificação de invariante falhou ao tentar reivindicar o custo da transação. Adicionado pela \[emenda EnforceInvariants]\[]. Se você puder reproduzir este erro, por favor [reporte um problema](https://github.com/ripple/rippled/issues). | +| `tefMASTER_DISABLED` | A transação foi assinada com a chave mestre da conta, mas a conta tem o campo `lsfDisableMaster` definido. | +| `tefMAX_LEDGER` | A transação incluiu um parâmetro `LastLedgerSequence`, mas o número de sequência do ledger atual já é maior do que o valor especificado. | +| `tefNFTOKEN_IS_NOT_TRANSFERABLE` | A transação tentou enviar um token não fungível para outra conta, mas o `NFToken` tem o flag `lsfTransferable` desabilitado e a transferência não seria para ou do emissor. _(Adicionado pela \[emenda NonFungibleTokensV1_1]\[].)_ | +| `tefNO_AUTH_REQUIRED` | A \[transação TrustSet]\[] tentou marcar uma linha de confiança como autorizada, mas o flag `lsfRequireAuth` não está habilitado para a conta correspondente, então a autorização não é necessária. | +| `tefNO_TICKET` | A transação tentou usar um Ticket, mas o número `TicketSequence` especificado não existe no ledger e não pode ser criado no futuro porque é anterior ao número de sequência atual do remetente. | +| `tefNOT_MULTI_SIGNING` | A transação foi multi-assinada, mas a conta remetente não tem nenhuma SignerList definida. | +| `tefPAST_SEQ` | O número de sequência da transação é menor do que o número de sequência atual da conta que envia a transação. | +| `tefTOO_BIG` | A transação afetaria muitos objetos no ledger. Por exemplo, esta era uma \[transação AccountDelete]\[] mas a conta a ser excluída possui mais de 1000 objetos no ledger. | +| `tefWRONG_PRIOR` | A transação continha um campo `AccountTxnID` (ou o campo descontinuado `PreviousTxnID`), mas a transação especificada não corresponde à transação anterior da conta. | +| `tefPAST_IMPORT_SEQ` | A transação falhou porque o número de sequência de importação já foi usado. | +| `tefPAST_IMPORT_VL_SEQ` | A transação falhou porque o número de sequência da lista de validadores de importação já foi usado. | diff --git a/src/content/docs/br/docs/protocol-reference/transactions/transaction-results/tel-codes.mdx b/src/content/docs/br/docs/protocol-reference/transactions/transaction-results/tel-codes.mdx new file mode 100644 index 0000000..1c93e43 --- /dev/null +++ b/src/content/docs/br/docs/protocol-reference/transactions/transaction-results/tel-codes.mdx @@ -0,0 +1,28 @@ +--- +title: Códigos TEL +--- +Esses códigos indicam um erro no servidor local que processa a transação; é possível que outro servidor com uma configuração diferente ou nível de carga diferente possa processar a transação com sucesso. Eles têm valores numéricos na faixa de -399 a -300. O código exato para qualquer erro específico está sujeito a alterações, portanto não dependa dele. + +**Cuidado:** Transações com códigos `tel` não são aplicadas a ledgers e não podem causar nenhuma mudança no estado do Xahau. No entanto, essas transações podem ser automaticamente armazenadas em cache e repetidas mais tarde. Transações que falharam provisoriamente ainda podem ter sucesso ou falhar com um código diferente após serem reaplicadas. Para mais informações, consulte Finalidade dos Resultados e Envio Confiável de Transações. + +| Código | Explicação | +| ---------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| `telBAD_DOMAIN` | A transação especificou um valor de domínio (por exemplo, o campo `Domain` de uma \[transação AccountSet]\[]) que não pode ser usado, provavelmente porque é muito longo para ser armazenado no ledger. | +| `telBAD_PATH_COUNT` | A transação contém muitos caminhos para o servidor local processar. | +| `telBAD_PUBLIC_KEY` | A transação especificou um valor de chave pública (por exemplo, como o campo `MessageKey` de uma \[transação AccountSet]\[]) que não pode ser usado, provavelmente porque não tem o comprimento correto. | +| `telCAN_NOT_QUEUE` | A transação não atendeu ao custo do ledger aberto, mas este servidor não enfileirou esta transação porque não atendeu às restrições de enfileiramento. Por exemplo, uma transação retorna este código quando o remetente já tem 10 outras transações na fila. Você pode tentar novamente mais tarde ou assinar e enviar uma transação substituta com um custo de transação mais alto no campo `Fee`. | +| `telCAN_NOT_QUEUE_BALANCE` | A transação não atendeu ao custo do ledger aberto e também não foi adicionada à fila de transações porque a soma dos custos potenciais de XAH das transações já enfileiradas é maior do que o saldo esperado da conta. Você pode tentar novamente mais tarde ou tentar enviar para um servidor diferente. | +| `telCAN_NOT_QUEUE_BLOCKS` | A transação não atendeu ao custo do ledger aberto e também não foi adicionada à fila de transações. Esta transação não pôde substituir uma transação existente na fila porque bloquearia transações já enfileiradas do mesmo remetente ao alterar métodos de autorização. (Isso inclui todas as transações \[SetRegularKey]\[] e \[SignerListSet]\[], bem como transações \[AccountSet]\[] que alteram os flags `RequireAuth`/`OptionalAuth`, `DisableMaster` ou `AccountTxnID`.) Você pode tentar novamente mais tarde ou tentar enviar para um servidor diferente. | +| `telCAN_NOT_QUEUE_BLOCKED` | A transação não atendeu ao custo do ledger aberto e também não foi adicionada à fila de transações porque uma transação enfileirada antes dela do mesmo remetente a bloqueia. (Isso inclui todas as transações \[SetRegularKey]\[] e \[SignerListSet]\[], bem como transações \[AccountSet]\[] que alteram os flags `RequireAuth`/`OptionalAuth`, `DisableMaster` ou `AccountTxnID`.) Você pode tentar novamente mais tarde ou tentar enviar para um servidor diferente. | +| `telCAN_NOT_QUEUE_FEE` | A transação não atendeu ao custo do ledger aberto e também não foi adicionada à fila de transações. Este código ocorre quando uma transação com o mesmo remetente e número de sequência já existe na fila e a nova não paga um custo de transação suficientemente alto para substituir a transação existente. Para substituir uma transação na fila, a nova transação deve ter um valor `Fee` que seja pelo menos 25% maior, medido em níveis de taxa. Você pode aumentar o `Fee` e tentar novamente, enviar com um número `Sequence` mais alto para não substituir uma transação existente, ou tentar enviar para outro servidor. | +| `telCAN_NOT_QUEUE_FULL` | A transação não atendeu ao custo do ledger aberto e o servidor não enfileirou esta transação porque a fila de transações deste servidor está cheia. Você pode aumentar o `Fee` e tentar novamente, tentar novamente mais tarde ou tentar enviar para um servidor diferente. A nova transação deve ter um custo de transação mais alto, medido em níveis de taxa, do que a transação na fila com o menor custo de transação. | +| `telFAILED_PROCESSING` | Um erro não especificado ocorreu ao processar a transação. | +| `telINSUF_FEE_P` | A `Fee` da transação não é suficientemente alta para atender ao requisito de custo de transação atual do servidor, que é derivado de seu nível de carga e requisitos de nível de rede. Se o servidor individual estiver muito ocupado para processar sua transação agora, ele pode armazenar em cache a transação e tentar novamente automaticamente mais tarde. | +| `telLOCAL_ERROR` | Erro local não especificado. | +| `telNO_DST_PARTIAL` | A transação é um pagamento XAH que financiaria uma nova conta, mas o flag `tfPartialPayment` estava habilitado. Isso não é permitido. | +| `telWRONG_NETWORK` | A transação especifica um valor `NetworkID` errado para a rede atual. Especifique o valor correto de `NetworkID` para a rede pretendida ou envie a transação para um servidor conectado à rede correta. | +| `telREQUIRES_NETWORK_ID` | A transação não especifica um campo `NetworkID`, mas a rede atual exige um. Se a transação foi destinada a uma rede que requer `NetworkID`, adicione o campo e tente novamente. Se a transação foi destinada a uma rede diferente, envie-a para um servidor conectado à rede correta. | +| `telNETWORK_ID_MAKES_TX_NON_CANONICAL` | A transação especificou um campo `NetworkID`, mas a rede atual exige que o `NetworkID` não seja enviado. | +| `telNON_LOCAL_EMITTED_TXN` | A transação emitida não pode ser aplicada porque não foi gerada localmente. | +| `telIMPORT_VL_KEY_NOT_RECOGNISED` | A transação foi assinada em uma rede diferente ou foi enviada para a rede errada. Para transações `Import`, as validações devem corresponder às chaves vl na rede receptora. | +| `telCAN_NOT_QUEUE_IMPORT` | A transação `Import` não pôde ser aplicada diretamente e não pode ser enfileirada. | diff --git a/src/content/docs/br/docs/protocol-reference/transactions/transaction-results/tem-codes.mdx b/src/content/docs/br/docs/protocol-reference/transactions/transaction-results/tem-codes.mdx new file mode 100644 index 0000000..aacfbf6 --- /dev/null +++ b/src/content/docs/br/docs/protocol-reference/transactions/transaction-results/tem-codes.mdx @@ -0,0 +1,46 @@ +--- +title: Códigos TEM +--- +Esses códigos indicam que a transação estava malformada e não pode ter sucesso de acordo com o protocolo Xahau. Eles têm valores numéricos na faixa de -299 a -200. O código exato para qualquer erro específico está sujeito a alterações, portanto não dependa dele. + +**Dica:** Transações com códigos `tem` não são aplicadas a ledgers e não podem causar nenhuma mudança no estado do Xahau. Um resultado `tem` é definitivo, a menos que as regras para uma transação válida mudem. (Por exemplo, usar funcionalidade de uma Emenda antes que essa emenda seja habilitada resulta em `temDISABLED`; tal transação poderia ter sucesso posteriormente se se tornar válida quando a emenda for habilitada.) + +| Código | Explicação | +| ------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `temBAD_AMOUNT` | Um valor especificado pela transação (por exemplo, o `Amount` de destino ou os valores `SendMax` de um \[Pagamento]\[]) era inválido, possivelmente porque era um número negativo. | +| `temBAD_AUTH_MASTER` | A chave usada para assinar esta transação não corresponde à chave mestre da conta que a envia, e a conta não tem uma Chave Regular definida. | +| `temBAD_CURRENCY` | A transação especificou incorretamente um campo de moeda. Consulte \[Especificando Valores em Moeda]\[Valor em Moeda] para o formato correto. | +| `temBAD_EXPIRATION` | A transação especificou incorretamente um valor de expiração, por exemplo como parte de uma \[transação OfferCreate]\[]. Alternativamente, a transação não especificou um valor de expiração obrigatório, por exemplo como parte de uma \[transação EscrowCreate]\[]. | +| `temBAD_FEE` | A transação especificou incorretamente seu valor `Fee`, por exemplo listando uma moeda que não é XAH ou alguma quantidade negativa de XAH. | +| `temBAD_ISSUER` | A transação especificou incorretamente o campo `issuer` de alguma moeda incluída na solicitação. | +| `temBAD_LIMIT` | A \[transação TrustSet]\[] especificou incorretamente o valor `LimitAmount` de uma linha de confiança. | +| `temBAD_NFTOKEN_TRANSFER_FEE` | A \[transação NFTokenMint]\[] especificou incorretamente o campo `TransferFee` da transação. _(Adicionado pela \[emenda NonFungibleTokensV1_1]\[].)_ | +| `temBAD_OFFER` | A \[transação OfferCreate]\[] especifica uma oferta inválida, como oferecer trocar XAH por si mesmo, ou oferecer uma quantidade negativa. | +| `temBAD_PATH` | A \[transação Payment]\[] especifica um ou mais Caminhos incorretamente, por exemplo incluindo um emissor para XAH, ou especificando uma conta de forma diferente. | +| `temBAD_PATH_LOOP` | Um dos Caminhos na \[transação Payment]\[] foi identificado como um loop, portanto não pode ser processado em uma quantidade limitada de tempo. | +| `temBAD_SEND_NATIVE_LIMIT` | A \[transação Payment]\[] usou o flag `tfLimitQuality` em um pagamento direto XAH-para-XAH, embora pagamentos XAH-para-XAH não envolvam nenhuma conversão. | +| `temBAD_SEND_NATIVE_MAX` | A \[transação Payment]\[] incluiu um campo `SendMax` em um pagamento direto XAH-para-XAH, embora o envio de XAH nunca deva exigir `SendMax`. (XAH só é válido em `SendMax` se o `Amount` de destino não for XAH.) | +| `temBAD_SEND_NATIVE_NO_DIRECT` | A \[transação Payment]\[] usou o flag `tfNoDirectRipple` para um pagamento direto XAH-para-XAH, embora pagamentos XAH-para-XAH sejam sempre diretos. | +| `temBAD_SEND_NATIVE_PARTIAL` | A \[transação Payment]\[] usou o flag `tfPartialPayment` para um pagamento direto XAH-para-XAH, embora pagamentos XAH-para-XAH devam sempre entregar o valor total. | +| `temBAD_SEND_NATIVE_PATHS` | A \[transação Payment]\[] incluiu `Paths` ao enviar XAH, embora pagamentos XAH-para-XAH devam sempre ser diretos. | +| `temBAD_SEQUENCE` | A transação referencia um número de sequência que é maior do que seu próprio número `Sequence`, por exemplo tentando cancelar uma oferta que teria que ser colocada após a transação que a cancela. | +| `temBAD_SIGNATURE` | A assinatura para autorizar esta transação está ausente ou formada de uma maneira que não é uma assinatura propriamente formada. (Consulte `tecNO_PERMISSION` para o caso em que a assinatura está propriamente formada, mas não está autorizada para esta conta.) | +| `temBAD_SRC_ACCOUNT` | A `Account` em cujo nome esta transação está sendo enviada (a "conta de origem") não é um endereço de conta propriamente formado. | +| `temBAD_TRANSFER_RATE` | O campo `TransferRate` de uma transação AccountSet não está formatado corretamente ou está fora do intervalo aceitável. | +| `temCANNOT_PREAUTH_SELF` | O remetente da \[transação DepositPreauth]\[] também foi especificado como a conta a pré-autorizar. Você não pode pré-autorizar a si mesmo. | +| `temDST_IS_SRC` | A transação especificou incorretamente um endereço de destino como a `Account` que envia a transação. Isso inclui linhas de confiança (onde o endereço de destino é o campo `issuer` de `LimitAmount`) e canais de pagamento (onde o endereço de destino é o campo `Destination`). | +| `temDST_NEEDED` | A transação omitiu incorretamente um destino. Pode ser o campo `Destination` de uma \[transação Payment]\[], ou o subcampo `issuer` do campo `LimitAmount` de uma transação `TrustSet`. | +| `temINVALID` | A transação é inválida por outros motivos. Por exemplo, o ID da transação pode não estar no formato correto, a assinatura pode não estar formada corretamente, ou algo mais deu errado ao entender a transação. | +| `temINVALID_COUNT` | A transação inclui um campo `TicketCount`, mas o número de Tickets especificado é inválido. | +| `temINVALID_FLAG` | A transação inclui um Flag que não existe, ou inclui uma combinação contraditória de flags. | +| `temMALFORMED` | Problema não especificado com o formato da transação. | +| `temREDUNDANT` | A transação não faria nada; por exemplo, está enviando um pagamento diretamente para a conta remetente, ou criando uma oferta para comprar e vender a mesma moeda do mesmo emissor. | +| `temREDUNDANT_SEND_MAX` | \[Removido em: rippled 0.28.0]\[] | +| `temRIPPLE_EMPTY` | A \[transação Payment]\[] inclui um campo `Paths` vazio, mas caminhos são necessários para completar este pagamento. | +| `temBAD_WEIGHT` | A \[transação SignerListSet]\[] inclui um `SignerWeight` que é inválido, por exemplo um valor zero ou negativo. | +| `temBAD_SIGNER` | A \[transação SignerListSet]\[] inclui um signatário que é inválido. Por exemplo, pode haver entradas duplicadas, ou o proprietário da SignerList também pode ser um membro. | +| `temBAD_QUORUM` | A \[transação SignerListSet]\[] tem um valor `SignerQuorum` inválido. O valor não é maior que zero, ou é maior do que a soma de todos os signatários na lista. | +| `temUNCERTAIN` | Usado apenas internamente. Este código nunca deve ser retornado. | +| `temUNKNOWN` | Usado apenas internamente. Este código nunca deve ser retornado. | +| `temDISABLED` | A transação requer lógica que está desabilitada. Normalmente isso significa que você está tentando usar uma emenda que não está habilitada para o ledger atual. | +| `temHOOK_DATA_TOO_LARGE` | O campo `CreateCode` da transação contém mais de 256 bytes. | diff --git a/src/content/docs/br/docs/protocol-reference/transactions/transaction-results/ter-codes.mdx b/src/content/docs/br/docs/protocol-reference/transactions/transaction-results/ter-codes.mdx new file mode 100644 index 0000000..f1d90cd --- /dev/null +++ b/src/content/docs/br/docs/protocol-reference/transactions/transaction-results/ter-codes.mdx @@ -0,0 +1,22 @@ +--- +title: Códigos TER +--- +Esses códigos indicam que a transação falhou, mas poderia ser aplicada com sucesso no futuro, geralmente se alguma outra transação hipotética for aplicada primeiro. Eles têm valores numéricos na faixa de -99 a -1. O código exato para qualquer erro específico está sujeito a alterações, portanto não dependa dele. + +**Cuidado:** Transações com códigos `ter` não são aplicadas ao ledger atual e não podem causar nenhuma mudança no estado do Xahau. No entanto, uma transação que falhou provisoriamente ainda pode ter sucesso ou falhar com um código diferente após ser automaticamente reaplicada. Para mais informações, consulte Finalidade dos Resultados e Envio Confiável de Transações. + +| Código | Explicação | +| ---------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `terFUNDS_SPENT` | **DESCONTINUADO.** | +| `terINSUF_FEE_B` | A conta que envia a transação não tem XAH suficiente para pagar a `Fee` especificada na transação. | +| `terLAST` | Usado apenas internamente. Este código nunca deve ser retornado. | +| `terNO_ACCOUNT` | O endereço que envia a transação não está financiado no ledger (ainda). | +| `terNO_AUTH` | A transação envolveria adicionar moeda emitida por uma conta com `lsfRequireAuth` habilitado a uma linha de confiança que não está autorizada. Por exemplo, você colocou uma oferta para comprar uma moeda que não está autorizado a manter. | +| `terNO_LINE` | Usado apenas internamente. Este código nunca deve ser retornado. | +| `terNO_RIPPLE` | Usado apenas internamente. Este código nunca deve ser retornado. | +| `terOWNERS` | A transação requer que a conta que a envia tenha uma "contagem de proprietários" diferente de zero, portanto a transação não pode ter sucesso. Por exemplo, uma conta não pode habilitar o flag `lsfRequireAuth` se tiver linhas de confiança ou ofertas disponíveis. | +| `terPRE_SEQ` | O número `Sequence` da transação atual é maior do que o número de sequência atual da conta que envia a transação. | +| `terPRE_TICKET` | A transação tentou usar um Ticket, mas o número `TicketSequence` especificado não existe no ledger. No entanto, o Ticket ainda pode ser criado por outra transação. | +| `terRETRY` | Erro retriável não especificado. | +| `terQUEUED` | A transação atendeu ao custo de transação com escalonamento de carga, mas não atendeu ao requisito do ledger aberto, portanto a transação foi enfileirada para um ledger futuro. | +| `terNO_HOOK` | A transação tentou usar um `HookHash` que não existe no ledger. | diff --git a/src/content/docs/br/docs/protocol-reference/transactions/transaction-results/tes-codes.mdx b/src/content/docs/br/docs/protocol-reference/transactions/transaction-results/tes-codes.mdx new file mode 100644 index 0000000..7d0cdd5 --- /dev/null +++ b/src/content/docs/br/docs/protocol-reference/transactions/transaction-results/tes-codes.mdx @@ -0,0 +1,11 @@ +--- +title: Códigos TES +--- +Os códigos `tesSUCCESS` e `tesPARTIAL` são os únicos códigos que indicam que uma transação foi bem-sucedida. Isso nem sempre significa que ela realizou o que você esperava. (Por exemplo, um \[OfferCancel]\[] pode "ter sucesso" mesmo que não haja nenhuma oferta para cancelar.) + +O código `tesPARTIAL` indica que uma transação teve sucesso parcial. Especificamente, é usado em cenários onde uma operação, como excluir registros de estado de hook, excede um determinado limite (por exemplo, 512 ou 1024 registros). Nesses casos, a transação exclui até o limite e então exige que você envie transações adicionais com novos números de sequência para continuar o processo de exclusão até que todos os registros sejam removidos. Isso garante que grandes operações sejam divididas em partes gerenciáveis. + +| Código | Explicação | +| ------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `tesSUCCESS` | A transação foi aplicada e encaminhada para outros servidores. Se aparecer em um ledger validado, o sucesso da transação é definitivo. | +| `tesPARTIAL` | A transação teve sucesso parcial e requer transações adicionais para concluir grandes operações, como excluir mais do que um limite definido de registros. | diff --git a/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/accountdelete.mdx b/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/accountdelete.mdx new file mode 100644 index 0000000..c95328b --- /dev/null +++ b/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/accountdelete.mdx @@ -0,0 +1,61 @@ +--- +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_ + + + +### 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. | + diff --git a/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/accountset.mdx b/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/accountset.mdx new file mode 100644 index 0000000..b425ac9 --- /dev/null +++ b/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/accountset.mdx @@ -0,0 +1,116 @@ +--- +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. + +
Flag NameHex ValueDecimal ValueReplaced by AccountSet Flag
tfRequireDestTag0x0001000065536asfRequireDest (SetFlag)
tfOptionalDestTag0x00020000131072asfRequireDest (ClearFlag)
tfRequireAuth0x00040000262144asfRequireAuth (SetFlag)
tfOptionalAuth0x00080000524288asfRequireAuth (ClearFlag)
tfDisallowXRP0x001000001048576asfDisallowXRP (SetFlag)
tfAllowXRP0x002000002097152asfDisallowXRP (ClearFlag)
+ +**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. diff --git a/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/checkcancel.mdx b/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/checkcancel.mdx new file mode 100644 index 0000000..4138e10 --- /dev/null +++ b/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/checkcancel.mdx @@ -0,0 +1,30 @@ +--- +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`. diff --git a/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/checkcash.mdx b/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/checkcash.mdx new file mode 100644 index 0000000..611f14b --- /dev/null +++ b/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/checkcash.mdx @@ -0,0 +1,38 @@ +--- +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`. diff --git a/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/checkcreate.mdx b/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/checkcreate.mdx new file mode 100644 index 0000000..cf8c2f6 --- /dev/null +++ b/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/checkcreate.mdx @@ -0,0 +1,44 @@ +--- +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`. diff --git a/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/claimreward.mdx b/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/claimreward.mdx new file mode 100644 index 0000000..d836534 --- /dev/null +++ b/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/claimreward.mdx @@ -0,0 +1,62 @@ +--- +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. | diff --git a/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/clawback.mdx b/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/clawback.mdx new file mode 100644 index 0000000..d7102af --- /dev/null +++ b/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/clawback.mdx @@ -0,0 +1,52 @@ +--- +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. | + diff --git a/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/cronset.mdx b/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/cronset.mdx new file mode 100644 index 0000000..ed969e7 --- /dev/null +++ b/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/cronset.mdx @@ -0,0 +1,101 @@ +--- +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. | diff --git a/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/depositpreauth.mdx b/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/depositpreauth.mdx new file mode 100644 index 0000000..542e4e9 --- /dev/null +++ b/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/depositpreauth.mdx @@ -0,0 +1,45 @@ +--- +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'; + + + +\[[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`. diff --git a/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/escrowcancel.mdx b/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/escrowcancel.mdx new file mode 100644 index 0000000..568d1e9 --- /dev/null +++ b/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/escrowcancel.mdx @@ -0,0 +1,42 @@ +--- +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. diff --git a/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/escrowcreate.mdx b/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/escrowcreate.mdx new file mode 100644 index 0000000..601edb1 --- /dev/null +++ b/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/escrowcreate.mdx @@ -0,0 +1,43 @@ +--- +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]\[] + diff --git a/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/escrowfinish.mdx b/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/escrowfinish.mdx new file mode 100644 index 0000000..20e5855 --- /dev/null +++ b/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/escrowfinish.mdx @@ -0,0 +1,53 @@ +--- +title: EscrowFinish +description: Deliver XAH or IOU from a held payment to the recipient. +--- +\[[Source](https://github.com/Xahau/xahaud/blob/dev/src/ripple/app/tx/impl/URIToken.cpp)] + +_Added by the \[Escrow amendment]\[]._ + +### Finish with OfferSequence + +```json +{ + "Account": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn", + "TransactionType": "EscrowFinish", + "Owner": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn", + "OfferSequence": 7, + "Condition": "A0258020E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855810100", + "Fulfillment": "A0028000" +} +``` + +### Finish with EscrowID + +```json +{ + "Account": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn", + "TransactionType": "EscrowFinish", + "Owner": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn", + "EscrowID": "49647F0D748DC3FE26BDACBC57F251AADEFFF391403EC9BF87C97F67E9977FB0", + "Condition": "A0258020E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855810100", + "Fulfillment": "A0028000" +} +``` + +### Fields + +| Field | JSON Type | \[Internal Type]\[] | Description | +| --------------- | --------- | ------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `Owner` | String | AccountID | Address of the source account that funded the held payment. | +| `OfferSequence` | Number | UInt32 | _(Optional)_ Transaction sequence of \[EscrowCreate transaction]\[] that created the held payment to finish. | +| `Condition` | String | Blob | _(Optional)_ Hex value matching the previously-supplied [PREIMAGE-SHA-256 crypto-condition](https://tools.ietf.org/html/draft-thomas-crypto-conditions-02#section-8.1) of the held payment. | +| `Fulfillment` | String | Blob | _(Optional)_ Hex value of the [PREIMAGE-SHA-256 crypto-condition fulfillment](https://tools.ietf.org/html/draft-thomas-crypto-conditions-02#section-8.1.4) matching the held payment's `Condition`. | +| `EscrowID` | String | Hash256 | _(Optional)_ The ID of the Escrow ledger object to finish, as a 64-character hexadecimal string. | + +Any account may submit an EscrowFinish transaction. + +* If the held payment has a `FinishAfter` time, you cannot execute it before this time. Specifically, if the corresponding \[EscrowCreate transaction]\[] specified a `FinishAfter` time that is after the close time of the most recently-closed ledger, the EscrowFinish transaction fails. +* If the held payment has a `Condition`, you cannot execute it unless you provide a matching `Fulfillment` for the condition. +* You cannot execute a held payment after it has expired. Specifically, if the corresponding \[EscrowCreate transaction]\[] specified a `CancelAfter` time that is before the close time of the most recently-closed ledger, the EscrowFinish transaction fails. + +**Note:** The minimum transaction cost to submit an EscrowFinish transaction increases if it contains a fulfillment. If the transaction has no fulfillment, the transaction cost is the standard 10 drops. If the transaction contains a fulfillment, the transaction cost is 330 \[drops of XAH]\[] plus another 10 drops for every 16 bytes in size of the preimage. + +In non-production networks, it may be possible to delete the destination account of a pending escrow. In this case, an attempt to finish the escrow fails with the result `tecNO_TARGET`, but the escrow object remains unless it has expired normally. If another payment re-creates the destination account, the escrow can be finished successfully. The destination account of an escrow can only be deleted if the escrow was created before the fix1523 amendment became enabled. No such escrows exist in the production Xahau, so this edge case is not possible on the production Xahau. This edge case is also not possible in test networks that enable both fix1523 and Escrow amendments at the same time, which is the default when you start a new genesis ledger. diff --git a/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/genesismint-emitted-txn.mdx b/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/genesismint-emitted-txn.mdx new file mode 100644 index 0000000..213ef81 --- /dev/null +++ b/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/genesismint-emitted-txn.mdx @@ -0,0 +1,57 @@ +--- +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. | diff --git a/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/import.mdx b/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/import.mdx new file mode 100644 index 0000000..52adf5f --- /dev/null +++ b/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/import.mdx @@ -0,0 +1,64 @@ +--- +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._ diff --git a/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/index.mdx b/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/index.mdx new file mode 100644 index 0000000..3f9060d --- /dev/null +++ b/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/index.mdx @@ -0,0 +1,12 @@ +--- +title: Tipos de Transação +--- +## Tipos de Transação + +O tipo de uma transação (campo `TransactionType`) é a informação mais fundamental sobre uma transação. Isso indica que tipo de operação a transação deve realizar. + +Todas as transações possuem certos campos em comum: + +* Campos Comuns + +Cada tipo de transação possui campos adicionais relevantes ao tipo de ação que causa. diff --git a/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/invoke.mdx b/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/invoke.mdx new file mode 100644 index 0000000..57e6c3f --- /dev/null +++ b/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/invoke.mdx @@ -0,0 +1,40 @@ +--- +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. | diff --git a/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/offercancel.mdx b/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/offercancel.mdx new file mode 100644 index 0000000..9415a18 --- /dev/null +++ b/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/offercancel.mdx @@ -0,0 +1,44 @@ +--- +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. diff --git a/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/offercreate.mdx b/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/offercreate.mdx new file mode 100644 index 0000000..038ac9d --- /dev/null +++ b/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/offercreate.mdx @@ -0,0 +1,68 @@ +--- +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. | diff --git a/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/payment.mdx b/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/payment.mdx new file mode 100644 index 0000000..fc9ed86 --- /dev/null +++ b/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/payment.mdx @@ -0,0 +1,113 @@ +--- +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. diff --git a/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/paymentchannelclaim.mdx b/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/paymentchannelclaim.mdx new file mode 100644 index 0000000..1dd34ae --- /dev/null +++ b/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/paymentchannelclaim.mdx @@ -0,0 +1,60 @@ +--- +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. | diff --git a/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/paymentchannelcreate.mdx b/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/paymentchannelcreate.mdx new file mode 100644 index 0000000..6c87588 --- /dev/null +++ b/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/paymentchannelcreate.mdx @@ -0,0 +1,40 @@ +--- +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:)_ diff --git a/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/paymentchannelfund.mdx b/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/paymentchannelfund.mdx new file mode 100644 index 0000000..c12bf58 --- /dev/null +++ b/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/paymentchannelfund.mdx @@ -0,0 +1,46 @@ +--- +title: PaymentChannelFund +description: >- + Add additional Amount to an open payment channel, and optionally update the + expiration time of the channel. Only the source address of the channel can use + this transaction. +--- +[\[Source\]](https://github.com/ripple/rippled/blob/master/src/ripple/app/tx/impl/PayChan.cpp) + +_Added by the \[PayChan amendment]\[]._ + +### Example + +```json +{ + "Account": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn", + "TransactionType": "PaymentChannelFund", + "Channel": "C1AE6DDDEEC05CF2978C0BAD6FE302948E9533691DC749DCDD3B9E5992CA6198", + "Amount" : { + "currency" : "USD", + "value" : "1", + "issuer" : "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn" + }, + "Expiration": 543171558 +} +``` + +| Field | JSON Type | \[Internal Type]\[] | Description | +| ------------ | ---------------------------------------------------------------------------------------------------------------------------------- | ------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `Channel` | String | Hash256 | The unique ID of the channel to fund, as a 64-character hexadecimal string. | +| `Amount` | [Currency Amount](/docs/protocol-reference/data-types/currency-formats/#specifying-currency-amounts) | Amount | Amount to add to the channel. Must be a positive amount. | +| `Expiration` | Number | UInt32 | _(Optional)_ New `Expiration` time to set for the channel, in \[seconds since the Ripple Epoch]\[]. This must be later than either the current time plus the `SettleDelay` of the channel, or the existing `Expiration` of the channel. After the `Expiration` time, any transaction that would access the channel closes the channel without taking its normal action. Any unspent Amount is returned to the source address when the channel closes. (`Expiration` is separate from the channel's immutable `CancelAfter` time.) For more information, see the PayChannel ledger object type. | + +### Error Cases + +Besides errors that can occur for all transactions, PaymentChannelFund transactions can result in the following transaction result codes: + +| Error Code | Description | +| ------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `tecINSUFFICIENT_RESERVE` | The sending account has less XAH than the reserve requirement. | +| `tecNO_DST` | The destination account of the channel has been deleted. This is only possible if the payment channel was created before the fixPayChanRecipientOwnerDir amendment became enabled (on 2020-05-01). | +| `tecNO_ENTRY` | The Payment Channel identified by the `Channel` field does not exist. | +| `tecNO_PERMISSION` | The sender of the transaction is not the source address for the channel. | +| `tecUNFUNDED` | The sending account does not have enough Amount to fund the channel with the requested amount and still meet the reserve requirement. | +| `temBAD_AMOUNT` | The `Amount` field of the transaction is invalid. The amount cannot be zero or negative. | +| `temBAD_EXPIRATION` | The `Expiration` field is invalid. | diff --git a/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/remit.mdx b/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/remit.mdx new file mode 100644 index 0000000..38b256e --- /dev/null +++ b/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/remit.mdx @@ -0,0 +1,119 @@ +--- +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'; + + + +\[[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) | diff --git a/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/sethook.mdx b/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/sethook.mdx new file mode 100644 index 0000000..41d2f86 --- /dev/null +++ b/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/sethook.mdx @@ -0,0 +1,364 @@ +--- +title: SetHook +description: >- + A transação SetHook permite que usuários instalem, atualizem, excluam ou realizem + outras operações em hooks no Xahau. +--- +\[[Fonte](https://github.com/Xahau/xahaud/blob/dev/src/ripple/app/tx/impl/SetHook.cpp)] + +_(Adicionado pela \[emenda Hooks]\[].)_ + +### Exemplo + +```json +{ + "TransactionType": "SetHook", + "Account": "rWYkbWkCeg8dP6rXALnjgZSjjLyih5NXm", + "Flags": 0, + "Hooks": [ + { + "Hook": { + "HookHash": "610F33B8EBF7EC795F822A454FB852156AEFE50BE0CB8326338A81CD74801864", + "CreateCode": "697066733A2F2F4445414442454546697066733A2F2F44454144424545467878", + "HookGrants": [], + "HookNamespace": "0000000000000000000000000000000000000000000000000000000000000000", + "HookParameters": [], + "HookOn": "0000000000000000000000000000000000000000000000000000000000000000", + "HookApiVersion": 0, + "Flags": 0 + } + } + ] +} +``` + +| Campo | Tipo JSON | \[Tipo Interno]\[] | Descrição | +| --------- | --------- | ------------------- | ---------------------------------------------------- | +| `Account` | String | AccountID | O endereço da conta que será proprietária do hook. | +| `Hooks` | Array | Array | O array de hooks a serem definidos. | + +### Custo Especial de Transação + +A transação SetHook tem um custo de transação padrão, que é o custo mínimo exigido para todas as transações. + +### Casos de Erro + +Além dos erros que podem ocorrer em todas as transações, as transações SetHook podem resultar nos seguintes códigos de resultado: + +| Código de Erro | Descrição | +| --------------- | ------------------------------------------------------------------------------------- | +| `tecDUPLICATE` | Ocorre se um hook com o mesmo hash já existir. | +| `tecDIR_FULL` | Ocorre se o diretório do proprietário estiver cheio e não puder acomodar o novo hook. | +| `terNO_ACCOUNT` | Ocorre se a conta remetente não existir. | +| `terNO_HOOK` | Ocorre se nenhum hook existir com o hash especificado. | +| `temDISABLED` | Ocorre se a Emenda Hooks não estiver habilitada. | +| `temMALFORMED` | Ocorre se a transação estiver malformada. | + +### Operações de SetHook + +Existem seis operações possíveis: Sem Operação, Criar, Atualizar, Excluir, Instalar e Exclusão de Namespace + +Cada operação é especificada pela inclusão ou omissão de certos campos do objeto HookSet. Isso pode parecer confuso no início, mas ao trabalhar com alguns exemplos, o leitor deve achar intuitivo; Essencialmente, as operações HookSet são um tipo de **diff** entre os _padrões_, _existentes_ e campos recém-especificados de um Hook específico. + +Como alcançar cada tipo de operação é explicado em uma subseção abaixo. + +### Sem Operação + +**Ocorre quando**: + +* O objeto HookSet está vazio + +**Comportamento**: + +* Nenhuma alteração de qualquer tipo é realizada. + +**Exemplo**: + +JSON + +```json +{ + Account: "r4GDFMLGJUKMjNhhycgt2d5LXCdXzCYPoc", + TransactionType: "SetHook", + Fee: "2000000", + Hooks: + [ + { + Hook: {} + } + ] +} +``` + +### Operação de Criação + +**Ocorre quando**: + +_Todas_ as seguintes condições são atendidas: + +* O Hook Correspondente não existe _ou_ `FLAG_OVERRIDE` é especificado. +* O campo `CreateCode` é especificado e não está em branco e contém o bytecode web assembly válido para um Hook válido. +* Nenhuma instância do mesmo bytecode web assembly já existe no XRPL. (Se existir e todos os outros requisitos forem atendidos, interprete como uma Operação de Instalação — veja abaixo.) + +**Comportamento**: + +* Um objeto `HookDefinition` com contagem de referência é criado no XRPL contendo os campos no objeto HookSet, com todos os campos especificados (Namespace, Parameters, HookOn) tornando-se padrões (mas não Grants). +* Um array `Hooks` é criado na conta executante, se ainda não existir. (Esta é a estrutura que contém os Hooks Correspondentes.) +* Um objeto `Hook` é criado na posição do Hook Correspondente se não existir. +* O objeto `Hook` aponta para a `HookDefinition`. +* O objeto `Hook` não contém campos exceto `HookHash` que aponta para a `HookDefinition` criada. +* Se o flag `hsfNSDELETE` for especificado, quaisquer entradas HookState no namespace de destino serão excluídas se existirem. + +**Exemplo**: + +JSON + +```json +{ + Account: "r4GDFMLGJUKMjNhhycgt2d5LXCdXzCYPoc", + TransactionType: "SetHook", + Fee: "2000000", + Hooks: + [ + { + Hook: { + CreateCode: fs.readFileSync('accept.wasm').toString('hex').toUpperCase(), + HookOn: '0000000000000000', + HookNamespace: addr.codec.sha256('accept').toString('hex').toUpperCase(), + HookApiVersion: 0 + } + } + ] +} +``` + +### Operação de Instalação + +**Ocorre quando**: + +_Todas_ as seguintes condições são atendidas: + +* O Hook Correspondente não existe _ou_ `FLAG_OVERRIDE` é especificado. +* O campo `HookHash` é especificado e não está em branco e contém o hash de um Hook que já existe como `HookDefinition` no ledger _ou_ o campo `CreateCode` é especificado e não está em branco e contém o bytecode web assembly válido para um hook válido que já existe no ledger como `HookDefinition`. + +**Comportamento**: + +* A contagem de referência do objeto `HookDefinition` é incrementada. +* Um array `Hooks` é criado na conta executante, se ainda não existir. (Esta é a estrutura que contém os Hooks Correspondentes.) +* Um objeto `Hook` é criado na posição do Hook Correspondente se não existir. +* O objeto `Hook` aponta para a `HookDefinition`. +* O objeto `Hook` contém todos os campos no objeto HookSet, exceto quando: +* Um campo ou par chave-valor dentro de um campo é idêntico aos Padrões de Hook definidos na `HookDefinition`, caso em que é omitido devido aos padrões. +* Se o flag `hsfNSDELETE` for especificado, quaisquer entradas HookState no namespace de destino serão excluídas se existirem. + +**Exemplo**: + +JSON + +```json +{ + Account: "r4GDFMLGJUKMjNhhycgt2d5LXCdXzCYPoc", + TransactionType: "SetHook", + Fee: "2000000", + Hooks: + [ + { + Hook: { + HookHash: "A5663784D04ED1B4408C6B97193464D27C9C3334AAF8BBB4FA5EB8E557FC4A2C", + HookOn: '0000000000000000', + HookNamespace: addr.codec.sha256('accept').toString('hex').toUpperCase(), + } + } + ] +} +``` + +### Operação de Atualização + +**Ocorre quando**: + +_Todas_ as seguintes condições são atendidas: + +* O Hook Correspondente existe. +* `HookHash` está ausente. +* `CreateCode` está ausente. +* Um ou mais de `HookNamespace`, `HookParameters` ou `HookGrants` está presente. + +**Comportamento Geral**: + +* O Hook Correspondente é atualizado de forma que as alterações desejadas sejam refletidas no Hook Correspondente. + +**Comportamento Específico**: + +Se `HookNamespace` for especificado e diferir do Namespace do Hook Correspondente: + +* O `HookNamespace` do Hook Correspondente é atualizado, e +* se o flag `hsfNSDELETE` for especificado, todas as entradas HookState no namespace antigo são excluídas. + +Se `HookParameters` for especificado, para cada entrada: + +* Se `HookParameterName` existir, mas `HookParameterValue` estiver ausente e os Parâmetros do Hook Correspondente (específicos ou via padrões) contiverem este `HookParameterName`, o parâmetro é marcado como excluído no Hook Correspondente. +* Se `HookParameterName` existir e `HookParameterValue` existir, os Parâmetros do Hook Correspondente são modificados para incluir o parâmetro novo ou atualizado. + +Se `HookGrants` for especificado: + +* O array `HookGrants` do Hook Correspondente é substituído pelo array. + +**Exemplo**: + +JSON + +```json +{ + Account: "r4GDFMLGJUKMjNhhycgt2d5LXCdXzCYPoc", + TransactionType: "SetHook", + Fee: "2000000", + Hooks: + [ + { + Hook: { + HookNamespace: addr.codec.sha256('new_accept').toString('hex').toUpperCase(), + } + } + ] +} +``` + +### Operação de Exclusão + +**Ocorre quando**: + +_Todas_ as seguintes condições são atendidas: + +* O Hook Correspondente existe. +* `hsfOVERRIDE` é especificado. +* opcionalmente `hsfNSDELETE` também é especificado. +* `HookHash` está ausente. +* `CreateCode` está presente, mas vazio. + +**Comportamento**: + +* A contagem de referência do objeto `HookDefinition` é decrementada. +* Se a contagem de referência for agora zero, a `HookDefintion` é removida do ledger. +* O objeto `Hook` na posição do Hook Correspondente é excluído, deixando uma posição vazia. +* Se `hsfNSDELETE` for especificado, o namespace e todas as entradas HookState também são excluídos. + +**Exemplo**: + +JSON + +```json +{ + Account: "r4GDFMLGJUKMjNhhycgt2d5LXCdXzCYPoc", + TransactionType: "SetHook", + Fee: "2000000", + Hooks: + [ + { + Hook: { + CreateCode: "", + Flags: 1, + } + } + ] +} +``` + +### Redefinição de Namespace + +**Ocorre quando**: + +_Todas_ as seguintes condições são atendidas: + +* `flags` está presente e `hsfNSDELETE` está definido. `hsfOVERRIDE` também pode opcionalmente ser especificado se o Hook nesta posição deve ser excluído. +* `HookNamespace` é especificado. +* `CreateCode` está ausente. +* `HookHash` está ausente. +* `HookGrants`, `HookParameters`, `HookOn` e `HookApiVersion` estão ausentes. + +**Comportamento**: + +* Se o Hook Correspondente existir, ele permanece; nada acontece com ele. +* Um subconjunto de objetos HookState e o diretório HookState para o namespace especificado são removidos do ledger, até o limite definido (512). Transações adicionais são necessárias para continuar o processo de exclusão até que todos os registros relevantes sejam removidos. Consulte [`tesPARTIAL`](/docs/protocol-reference/transactions/transaction-results/tes-codes). + +**Exemplo**: + +JSON + +```json +{ + Account: "r4GDFMLGJUKMjNhhycgt2d5LXCdXzCYPoc", + TransactionType: "SetHook", + Fee: "2000000", + Hooks: + [ + { + Hook: { + HookNamespace: addr.codec.sha256('accept').toString('hex').toUpperCase(), + Flags: 3, + } + } + ] +} +``` + +### Campos do Hook + +Os seguintes campos são usados no objeto hook: + +| Campo | Tipo JSON | Tipo Interno | Descrição | +| ---------------- | --------- | ------------- | ----------------------------------------------------- | +| `HookHash` | String | Hash256 | O hash do hook. | +| `CreateCode` | String | Blob | O código WebAssembly para o hook. | +| `HookGrants` | Array | Array | As concessões associadas ao hook. | +| `HookNamespace` | String | Hash256 | O namespace do hook. | +| `HookParameters` | Array | Array | Os parâmetros do hook. | +| `HookOn` | String | Hash256 | A(s) transação(ões) nas quais o hook é acionado. | +| `HookCanEmit` | String | Hash256 | A(s) transação(ões) que o hook pode emitir. | +| `HookApiVersion` | Number | UInt16 | A versão da API do hook. | +| `Flags` | Number | UInt32 | Flags adicionais para o hook. | + +### Flags + +O campo `Flags` no objeto hook especifica flags adicionais para o hook. Os seguintes flags são suportados: + +| Nome do Flag | Descrição | +| ------------- | --------------------------------------------------------------------------- | +| `hsfOVERRIDE` | Permite que o hook seja excluído mesmo que seja referenciado por outros objetos. | +| `hsfNSDELETE` | Exclui um namespace inteiro de hooks. | +| `hsfCOLLECT` | Coleta os objetos associados ao hook. | + +### Concessões de Hook + +O campo `HookGrants` é um array de objetos que especificam as concessões associadas ao hook. Cada objeto de concessão possui os seguintes campos: + +| Campo | Tipo JSON | Tipo Interno | Descrição | +| ----------- | --------- | ------------- | ------------------------------------------------------ | +| `HookHash` | String | Hash256 | O hook ao qual aplicar a concessão. | +| `Authorize` | String | AccountID | O endereço da conta à qual o acesso é concedido. | +| `Flags` | Number | Uint32 | Flags | + +### Parâmetros do Hook + +O campo `HookParameters` é um array de objetos que especificam os parâmetros do hook. Cada objeto de parâmetro possui os seguintes campos: + +| Campo | Tipo JSON | Tipo Interno | Descrição | +| -------------------- | --------- | ------------- | ---------------------------- | +| `HookParameterName` | String | Blob | O nome do parâmetro. | +| `HookParameterValue` | String | Blob | O valor do parâmetro. | + +### Execuções de Hook + +Quando Hooks são executados, eles deixam informações sobre o status dessa execução. Isso aparece nos metadados da Transação de Origem como um bloco `sfHookExecutions`. Este bloco contém os seguintes campos: + +| Campo | Tipo JSON | Tipo Interno | Descrição | +| ---------------------- | --------- | ------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `HookAccount` | String | AccountID | A conta na qual o Hook foi executado. | +| `HookEmitCount` | Number | UInt16 | O número total de Transações Emitidas produzidas pelo Hook. | +| `HookExecutionIndex` | Number | UInt16 | O SHA512H do Hook no momento em que foi executado. | +| `HookHash` | String | Hash256 | O valor do parâmetro. | +| `HookInstructionCount` | String | UInt64 | O número total de instruções webassembly que foram executadas quando o Hook foi executado. | +| `HookResult` | Number | UInt8 |

Hooks podem terminar de três maneiras: accept, rollback e error.
Isso _não_ é o mesmo que sfHookReturnCode!

| +| `HookReturnCode` | String | UInt64 | O inteiro retornado como terceiro parâmetro de `accept` ou `rollback`. | +| `HookReturnString` | String | Blob | A string retornada nos primeiros dois parâmetros de `accept` ou `rollback`, se houver. | +| `HookStateChangeCount` | Number | UInt16 | O número de mudanças de Estado do Hook que o Hook fez durante a execução. | diff --git a/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/setregularkey.mdx b/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/setregularkey.mdx new file mode 100644 index 0000000..969e12c --- /dev/null +++ b/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/setregularkey.mdx @@ -0,0 +1,33 @@ +--- +title: SetRegularKey +description: >- + Uma transação SetRegularKey atribui, altera ou remove o par de chaves regular + associado a uma conta. +--- +[\[Fonte\]](https://github.com/ripple/rippled/blob/4239880acb5e559446d2067f00dabb31cf102a23/src/ripple/app/transactors/SetRegularKey.cpp) + +Você pode proteger sua conta atribuindo um par de chaves regular a ela e usando-o em vez do par de chaves mestre para assinar transações sempre que possível. Se seu par de chaves regular for comprometido, mas seu par de chaves mestre não, você pode usar uma transação `SetRegularKey` para recuperar o controle de sua conta. + +### Exemplo de JSON SetRegularKey + +```json +{ + "Flags": 0, + "TransactionType": "SetRegularKey", + "Account": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn", + "Fee": "12", + "RegularKey": "rAR8rR8sUkBoCZFawhkWzY4Y5YoyuznwD" +} +``` + +| Campo | Tipo JSON | \[Tipo Interno]\[] | Descrição | +| ------------ | --------- | ------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `RegularKey` | String | AccountID | _(Opcional)_ Um \[Endereço]\[] codificado em base-58 que indica o par de chaves regular a ser atribuído à conta. Se omitido, remove qualquer par de chaves regular existente da conta. Não deve corresponder ao par de chaves mestre do endereço. | + +### Veja Também + +Para mais informações sobre pares de chaves regular e mestre, consulte Chaves Criptográficas. + +Para um tutorial sobre como atribuir um par de chaves regular a uma conta, consulte Trabalhando com um Par de Chaves Regular. + +Para uma segurança ainda maior, você pode usar multi-assinatura, mas a multi-assinatura requer XAH adicional para o \[custo de transação]\[] e a reserva. diff --git a/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/setremarks.mdx b/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/setremarks.mdx new file mode 100644 index 0000000..48588b4 --- /dev/null +++ b/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/setremarks.mdx @@ -0,0 +1,92 @@ +--- +title: SetRemarks +description: >- + A transação SetRemarks permite que contas anexem, atualizem ou removam + observações arbitrárias (pares chave-valor) em objetos de ledger suportados. +--- +\[[Fonte](https://github.com/Xahau/xahaud/blob/dev/src/ripple/app/tx/impl/SetRemarks.cpp)] + +_(Adicionado pela \[emenda Remarks]\[].)_ + +### Exemplo + +```json +{ + "TransactionType": "SetRemarks", + "Account": "rWYkbWkCeg8dP6rXALnjgZSjjLyih5NXm", + "Flags": 0, + "ObjectID": "AABBCCDDEEFF00112233445566778899AABBCCDDEEFF00112233445566778899", + "Remarks": [ + { + "Remark": { + "RemarkName": "CAFE", + "RemarkValue": "DEADBEEF", + "Flags": 0 + } + } + ] +} + +``` + +| Campo | Tipo JSON | Tipo Interno | Descrição | +| ---------- | --------- | ------------- | ------------------------------------------------------------------------------------------------------------ | +| `Account` | String | AccountID | O endereço da conta que envia a transação (deve ser o proprietário/emissor do objeto) | +| `ObjectID` | String | Hash256 | O ID do objeto de ledger ao qual as observações são anexadas (consulte Objetos Suportados) | +| `Remarks` | Array | Array | Array de objetos de observação a definir, atualizar ou excluir (consulte o Formato de Observações) | + +### Flags de SetRemarks + +| Nome da Flag | Valor Hex | Valor Decimal | Descrição | +| ------------- | ------------ | ------------- | --------------------------------------------------------------- | +| `tfImmutable` | `0x00000001` | 1 | Marca a observação como imutável (não pode ser alterada ou excluída) | + +### Formato de Observações + +Cada entrada no array `Remarks` é um objeto com um único campo `Remark`, que por sua vez é um objeto com os seguintes campos: + +| Campo | Tipo JSON | Tipo Interno | Obrigatório | Descrição | +| ------------- | --------- | ------------- | ----------- | ------------------------------------------------------------------------------------- | +| `RemarkName` | String | Blob | Sim | O nome/chave da observação (1–256 bytes, deve ser único por objeto) | +| `RemarkValue` | String | Blob | Não | O valor da observação (1–256 bytes). Omitir para excluir a observação. | +| `Flags` | Number | UInt32 | Não | Defina como `1` (`tfImmutable`) para tornar a observação imutável. Padrão é `0`. | + +### Objetos Suportados e Permissões + +Observações podem ser anexadas aos seguintes tipos de objetos de ledger. **Apenas a parte especificada (proprietário ou emissor) pode criar, atualizar ou excluir observações em cada objeto:** + +| Tipo de Objeto de Ledger | Quem Pode Definir Observações? | Notas | +| ------------------------------ | ------------------------------ | ---------------------------------------------------------------------------------------------- | +| **AccountRoot** | Proprietário | A própria conta (o endereço no objeto) | +| **Offer** | Proprietário | A conta que criou a oferta | +| **Escrow** | Proprietário | A conta que criou o escrow | +| **Ticket** | Proprietário | A conta que criou o ticket | +| **PayChannel** | Proprietário | A conta que criou o canal de pagamento | +| **Check** | Proprietário | A conta que criou o cheque | +| **DepositPreauth** | Proprietário | A conta que criou a pré-autorização de depósito | +| **URI Token** | Emissor | A conta que emitiu o URI Token (campo `sfIssuer`) | +| **Trustline (RippleState)** | Emissor | Apenas o lado emissor da linha de confiança (a conta que emitiu o IOU) pode definir observações. | + +### Limites + +* **Máximo de 32 observações** por objeto. +* Cada `RemarkName` e `RemarkValue` deve ter de 1 a 256 bytes. +* Cada `RemarkName` deve ser único por objeto. +* Uma vez que uma observação seja marcada como imutável (`Flags: 1`), ela não pode ser alterada ou excluída. + +### Custo Especial de Transação + +O custo base da transação é aumentado em **1 drop por byte** de todos os campos `RemarkName` e `RemarkValue` na transação. + +### Casos de Erro + +| Código de Erro | Descrição | +| --------------------- | ------------------------------------------------------------------------------------------------------- | +| `temDISABLED` | A emenda Remarks não está habilitada. | +| `temINVALID_FLAG` | Flags inválidas definidas na transação. | +| `temMALFORMED` | A transação está malformada (ex.: muitas observações, nomes duplicados, tamanhos de campo inválidos). | +| `terNO_ACCOUNT` | A conta remetente não existe. | +| `tecNO_TARGET` | O objeto alvo não existe. | +| `tecNO_PERMISSION` | O remetente não é o proprietário/emissor do objeto. | +| `tecIMMUTABLE` | Tentativa de modificar ou excluir uma observação imutável. | +| `tecTOO_MANY_REMARKS` | O número de observações no objeto excederia o limite de 32. | diff --git a/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/signerlistset.mdx b/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/signerlistset.mdx new file mode 100644 index 0000000..402cdf5 --- /dev/null +++ b/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/signerlistset.mdx @@ -0,0 +1,55 @@ +--- +title: SignerListSet +description: >- + A transação SignerListSet cria, substitui ou remove uma lista de signatários + que pode ser usada para assinar uma transação com múltiplas assinaturas. Este tipo de transação foi + introduzido pela [emenda MultiSign][]. +--- +[\[Fonte\]](https://github.com/Xahau/xahaud/blob/master/src/ripple/app/tx/impl/SetSignerList.cpp) + +### Exemplo + +```json +{ + "Flags": 0, + "TransactionType": "SignerListSet", + "Account": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn", + "Fee": "12", + "SignerQuorum": 3, + "SignerEntries": [ + { + "SignerEntry": { + "Account": "rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW", + "SignerWeight": 2 + } + }, + { + "SignerEntry": { + "Account": "rUpy3eEg8rqjqfUoLeBnZkscbKbFsKXC3v", + "SignerWeight": 1 + } + }, + { + "SignerEntry": { + "Account": "raKEEVSGnKSD9Zyvxu4z6Pqpm4ABH8FS6n", + "SignerWeight": 1 + } + } + ] +} +``` + +| Campo | Tipo JSON | \[Tipo Interno]\[] | Descrição | +| --------------- | --------- | ------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `SignerQuorum` | Number | UInt32 | Um número alvo para os pesos dos signatários. Uma assinatura múltipla desta lista é válida apenas se a soma dos pesos das assinaturas fornecidas for maior ou igual a este valor. Para excluir uma lista de signatários, use o valor `0`. | +| `SignerEntries` | Array | Array | _(Omitido ao excluir)_ Array de objetos `SignerEntry`, indicando os endereços e pesos dos signatários nesta lista. Esta lista de signatários deve ter pelo menos 1 membro e no máximo 32 membros. Nenhum endereço pode aparecer mais de uma vez na lista, nem a `Account` que envia a transação pode aparecer na lista. _(Atualizado pela \[emenda ExpandedSignerList]\[].)_ | + +Uma transação SignerListSet bem-sucedida substitui o objeto `SignerList` da conta no ledger, ou adiciona um se não existia antes. Uma conta não pode ter mais de uma lista de signatários. Para excluir uma lista de signatários, você deve definir `SignerQuorum` como `0` _e_ omitir o campo `SignerEntries`. Caso contrário, a transação falha com o erro `temMALFORMED`. Uma transação para excluir uma lista de signatários é considerada bem-sucedida mesmo que não houvesse lista de signatários para excluir. + +Você não pode criar uma lista de signatários onde o `SignerQuorum` nunca possa ser atingido. O `SignerQuorum` deve ser maior que 0, mas menor ou igual à soma dos valores `SignerWeight` na lista. Caso contrário, a transação falha com o erro `temMALFORMED`. + +Você pode criar, atualizar ou remover uma lista de signatários usando a chave mestre, chave regular ou a lista de signatários atual, se esses métodos de assinatura de transações estiverem disponíveis. + +Você não pode remover o último método de assinatura de transações de uma conta. Se a chave mestre de uma conta estiver desabilitada (a conta tem o flag `lsfDisableMaster` habilitado) e a conta não tiver uma Chave Regular configurada, então você não pode excluir a lista de signatários da conta. Em vez disso, a transação falha com o erro `tecNO_ALTERNATIVE_KEY`. + +Criar ou substituir uma lista de signatários habilita o flag `lsfOneOwnerCount` no objeto SignerList. Listas criadas antes da \[emenda MultiSignReserve]\[] ser habilitada não têm este flag e têm uma reserva de proprietário mais alta. Você pode diminuir a reserva de proprietário dessas listas substituindo a lista pela mesma lista. Para mais informações, consulte Flags de SignerList. diff --git a/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/ticketcreate.mdx b/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/ticketcreate.mdx new file mode 100644 index 0000000..4fe0806 --- /dev/null +++ b/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/ticketcreate.mdx @@ -0,0 +1,39 @@ +--- +title: TicketCreate +description: >- + Uma transação TicketCreate reserva um ou mais [números de sequência][Número de + Sequência] como Tickets. +--- +[\[Fonte\]](https://github.com/ripple/rippled/blob/develop/src/ripple/app/tx/impl/CreateTicket.cpp) + +_(Adicionado pela \[emenda TicketBatch]\[].)_ + +### Exemplo + +```json +{ + "TransactionType": "TicketCreate", + "Account": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn", + "Fee": "10", + "Sequence": 381, + "TicketCount": 10 +} +``` + +| Campo | Tipo JSON | \[Tipo Interno]\[] | Descrição | +| ------------- | --------- | ------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `TicketCount` | Number | UInt32 | Quantos Tickets criar. Deve ser um número positivo e não pode fazer com que a conta possua mais de 250 Tickets após a execução desta transação. | + +Se a transação não puder criar _todos_ os Tickets solicitados (seja devido ao limite de 250 Tickets ou à reserva do proprietário), ela falha e não cria nenhum Ticket. Para verificar quantos Tickets uma conta possui atualmente, use o \[método account_info]\[] e verifique o campo `account_data.TicketCount`. + +**Dica:** Esta transação aumenta o \[número de sequência]\[Número de Sequência] da conta remetente em 1 _mais_ o número de tickets criados (`TicketCount`). Esta é a única transação que aumenta o número de sequência de uma conta em mais de 1. + +### Casos de Erro + +Além dos erros que podem ocorrer em todas as transações, as transações TicketCreate podem resultar nos seguintes códigos de resultado: + +| Código de Erro | Descrição | +| ------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| `temINVALID_COUNT` | O campo `TicketCount` é inválido. Deve ser um inteiro de 1 a 250. | +| `tecDIR_FULL` | Esta transação faria com que a conta possuísse mais do que o limite de 250 Tickets de uma vez, ou mais do que o número máximo de objetos de ledger em geral. | +| `tecINSUFFICIENT_RESERVE` | A conta remetente não tem XAH suficiente para atender à reserva do proprietário de todos os Tickets solicitados. | diff --git a/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/trustset.mdx b/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/trustset.mdx new file mode 100644 index 0000000..fd63a7f --- /dev/null +++ b/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/trustset.mdx @@ -0,0 +1,65 @@ +--- +title: TrustSet +description: Cria ou modifica uma linha de confiança ligando duas contas. +--- +[\[Fonte\]](https://github.com/Xahau/xahaud/blob/master/src/ripple/app/tx/impl/SetTrust.cpp) + +### Exemplo + +```json +{ + "TransactionType": "TrustSet", + "Account": "ra5nK24KXen9AHvsdFTKHSANinZseWnPcX", + "Fee": "12", + "Flags": 262144, + "LastLedgerSequence": 8007750, + "LimitAmount": { + "currency": "USD", + "issuer": "rsP3mgGb2tcYUrxiLFiHJiQXhsziegtwBc", + "value": "100" + }, + "Sequence": 12 +} +``` + +| Campo | Tipo JSON | \[Tipo Interno]\[] | Descrição | +| ------------------------ | --------- | ------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `LimitAmount` | Object | Amount | Objeto que define a linha de confiança a criar ou modificar, no formato de um \[Valor em Moeda]\[]. | +| `LimitAmount`.`currency` | String | (Amount.currency) | A moeda à qual esta linha de confiança se aplica, como um [código de moeda ISO 4217](https://www.xe.com/iso4217.php) de três letras ou um valor hexadecimal de 160 bits. "XAH" é inválido. | +| `LimitAmount`.`value` | String | (Amount.value) | Representação decimal entre aspas do limite a definir nesta linha de confiança. | +| `LimitAmount`.`issuer` | String | (Amount.issuer) | O endereço da conta à qual estender confiança. | +| `QualityIn` | Number | UInt32 | _(Opcional)_ Avalia os saldos de entrada nesta linha de confiança na proporção deste número por 1.000.000.000 unidades. Um valor de `0` equivale a tratar os saldos pelo valor nominal. | +| `QualityOut` | Number | UInt32 | _(Opcional)_ Avalia os saldos de saída nesta linha de confiança na proporção deste número por 1.000.000.000 unidades. Um valor de `0` equivale a tratar os saldos pelo valor nominal. | + +Se a conta especificada em `LimitAmount.issuer` estiver bloqueando linhas de confiança de entrada, a transação falha com o código de resultado `tecNO_PERMISSION`. _(Requer a \[emenda DisallowIncoming]\[] :not_enabled:)_ + +### Flags de TrustSet + +Transações do tipo TrustSet suportam valores adicionais no campo `Flags`, como segue: + +| Nome da Flag | Valor Hex | Valor Decimal | Descrição | +| ----------------- | ------------ | ------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `tfSetfAuth` | `0x00010000` | 65536 | Autoriza a outra parte a manter moeda emitida por esta conta. (Sem efeito a menos que use o flag `asfRequireAuth` de AccountSet.) Não pode ser desfeito. | +| `tfSetNoRipple` | `0x00020000` | 131072 | Habilita o flag No Ripple, que bloqueia o rippling entre duas linhas de confiança da mesma moeda se este flag estiver habilitado em ambas. | +| `tfClearNoRipple` | `0x00040000` | 262144 | Desabilita o flag No Ripple, permitindo rippling nesta linha de confiança. | +| `tfSetFreeze` | `0x00100000` | 1048576 | Congela a linha de confiança. | +| `tfClearFreeze` | `0x00200000` | 2097152 | Descongela a linha de confiança. | +| `tfSetDeepFreeze` | `0x00400000` | 4194304 | Congela profundamente a linha de confiança. _(Requer a \[emenda DeepFreeze]\[])_ | +| `tfClearDeepFreeze` | `0x00800000` | 8388608 | Remove o congelamento profundo da linha de confiança. _(Requer a \[emenda DeepFreeze]\[])_ | + +Se uma transação tentar habilitar No Ripple mas não puder, ela falha com o código de resultado `tecNO_PERMISSION`. Antes da \[emenda fix1578]\[] ser habilitada, tal transação resultaria em `tesSUCCESS` (realizando quaisquer outras alterações possíveis) em vez disso. + +O flag Auth de uma linha de confiança não determina se a linha de confiança conta para o requisito de reserva de XAH do proprietário. No entanto, um flag Auth habilitado impede que a linha de confiança esteja em seu estado padrão. Uma linha de confiança autorizada nunca pode ser excluída. Um emissor pode pré-autorizar uma linha de confiança com o flag `tfSetfAuth` apenas, mesmo que o limite e o saldo da linha de confiança sejam 0. + +### Regras de Congelamento Profundo + +Com a \[emenda DeepFreeze]\[] habilitada, as seguintes regras se aplicam às operações de congelamento profundo: + +Uma transação TrustSet que tenta definir `tfSetDeepFreeze` é bem-sucedida se e somente se uma das seguintes condições for verdadeira: + +* O titular já está congelado, indicado por `lsfLowFreeze`/`lsfHighFreeze` na linha de confiança. +* `tfSetFreeze` também está definido na mesma transação TrustSet. + +Se a linha de confiança estiver profundamente congelada pelo emissor (indicado por `lsfLowDeepFreeze`/`lsfHighDeepFreeze`), a transação TrustSet falha se o emissor definir o flag `tfClearFreeze` sem também definir o flag `tfClearDeepFreeze`. Em outras palavras, o emissor não pode remover o congelamento regular de uma linha de confiança sem também remover o congelamento profundo. + +Consulte [Conta Alta vs. Conta Baixa](/docs/protocol-reference/ledger-data/ledger-objects-types/ripple-state#high-vs-low-account) para informações sobre como as contas baixa e alta são determinadas. diff --git a/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/uritokenburn.mdx b/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/uritokenburn.mdx new file mode 100644 index 0000000..413a552 --- /dev/null +++ b/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/uritokenburn.mdx @@ -0,0 +1,38 @@ +--- +title: URITokenBurn +description: >- + A transação URITokenBurn é usada para destruir um URIToken no Xahau. Destruir + um URIToken o remove permanentemente de circulação. +--- +[\[Fonte\]](https://github.com/ripple/rippled/blob/develop/src/ripple/app/tx/impl/URIToken.cpp) + +_(Adicionado pela \[emenda URIToken]\[].)_ + +A transação URITokenBurn é usada para destruir um URIToken no Xahau. Destruir um URIToken o remove permanentemente de circulação. + +### Exemplo + +```json +{ + "TransactionType": "URITokenBurn", + "Account": "rWYkbWkCeg8dP6rXALnjgZSjjLyih5NXm", + "URITokenID": "C1AE6DDDEEC05CF2978C0BAD6FE27362498DGS691DC749DCDD3B95992978C0BA", +} +``` + +| Campo | Tipo JSON | \[Tipo Interno]\[] | Descrição | +| ------------ | --------- | ------------------- | ----------------------------------------------------------------- | +| `Account` | String | AccountID | O endereço da conta que possui o URIToken a ser destruído. | +| `URITokenID` | String | Hash256 | O ID do URIToken a destruir. | + +### Custo Especial de Transação + +A transação URITokenBurn não possui requisitos especiais de custo de transação. + +### Casos de Erro + +Além dos erros que podem ocorrer em todas as transações, as transações URITokenBurn podem resultar nos seguintes códigos de resultado: + +| Código de Erro | Descrição | +| ------------------ | --------------------------------------------------------------------- | +| `tecNO_PERMISSION` | Ocorre se a conta não tiver permissão para destruir o token. | diff --git a/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/uritokenbuy.mdx b/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/uritokenbuy.mdx new file mode 100644 index 0000000..082e416 --- /dev/null +++ b/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/uritokenbuy.mdx @@ -0,0 +1,48 @@ +--- +title: URITokenBuy +description: >- + A transação URITokenBuy permite que um usuário compre um URIToken do emissor. + Esta transação é usada para transferir a propriedade de um URIToken do emissor + para o comprador. +--- +\[[Fonte](https://github.com/Xahau/xahaud/blob/dev/src/ripple/app/tx/impl/URIToken.cpp)] + +_(Adicionado pela \[emenda URIToken]\[].)_ + +### Exemplo + +```json +{ + "TransactionType": "URITokenBuy", + "Account": "rWYkbWkCeg8dP6rXALnjgZSjjLyih5NXm", + "URITokenID": "C1AE6DDDEEC05CF2978C0BAD6FE27362498DGS691DC749DCDD3B95992978C0BA", + "Amount": { + "issuer": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn", + "currency": "USD", + "value": "100", + }, +} +``` + +| Campo | Tipo JSON | \[Tipo Interno]\[] | Descrição | +| ------------ | ------------------------------------------------------------------------------------------------------------------------------------------ | ------------------- | ------------------------------------------------------- | +| `Account` | String | AccountID | O endereço da conta do comprador. | +| `URITokenID` | String | Hash256 | O identificador único do URIToken a ser comprado. | +| `Amount` | [Valor em Moeda](/docs/protocol-reference/data-types/currency-formats/#specifying-currency-amounts) | Amount | O valor da moeda a pagar pelo URIToken. | + +### Custo Especial de Transação + +A transação URITokenBuy tem um custo de transação padrão, que é a taxa mínima exigida para qualquer transação no Xahau. + +### Casos de Erro + +Além dos erros que podem ocorrer em todas as transações, as transações URITokenBuy podem resultar nos seguintes códigos de resultado: + +| Código de Erro | Descrição | +| ---------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------- | +| `tecCANT_ACCEPT_OWN_NFTOKEN_OFFER` | Ocorre se o proprietário do token for quem reivindica a oferta. | +| `tecDST_TAG_NEEDED` | Ocorre se a conta de destino exigir uma tag de destino, mas a transação não incluir uma. | +| `tecNO_PERMISSION` | Ocorre se o vendedor não tiver o token listado para venda ou se o `Destination` do token não for a conta que está comprando o token. | +| `temBAD_CURRENCY` | Ocorre quando a moeda de compra não corresponde à moeda da oferta. | +| `tecINSUFFICIENT_PAYMENT` | Ocorre quando o valor de compra é menor que o valor da oferta. | +| `tecINSUFFICIENT_FUNDS` | Ocorre quando o comprador não tem fundos suficientes, incluindo a `Fee`, para adquirir o token. | diff --git a/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/uritokencancelselloffer.mdx b/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/uritokencancelselloffer.mdx new file mode 100644 index 0000000..16b8468 --- /dev/null +++ b/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/uritokencancelselloffer.mdx @@ -0,0 +1,34 @@ +--- +title: URITokenCancelSellOffer +description: >- + Uma transação URITokenCancelSellOffer cancela uma oferta de venda de um URIToken no + Xahau. +--- +\[[Fonte](https://github.com/Xahau/xahaud/blob/dev/src/ripple/app/tx/impl/URIToken.cpp)] + +_(Adicionado pela \[emenda URIToken]\[].)_ + +### Exemplo + +```json +{ + "TransactionType": "URITokenCancelSellOffer", + "Account": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59", + "URITokenID": "C1AE6DDDEEC05CF2978C0BAD6FE27362498DGS691DC749DCDD3B95992978C0BA", +} +``` + +### Campos + +| Campo | Tipo JSON | \[Tipo Interno]\[] | Descrição | +| ------------ | --------- | ------------------- | ---------------------------------------------------------------- | +| `Account` | String | AccountID | O endereço da conta que possui a oferta de venda a cancelar. | +| `URITokenID` | String | Hash256 | O ID do URIToken para cancelar a oferta de venda. | + +### Casos de Erro + +Além dos erros que podem ocorrer em todas as transações, as transações URITokenCancelSellOffer podem resultar nos seguintes códigos de resultado: + +| Código de Erro | Descrição | +| ------------------ | ---------------------------------------------------------------------------- | +| `tecNO_PERMISSION` | Ocorre quando a conta que executa a transação não é a proprietária do token. | diff --git a/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/uritokencreateselloffer.mdx b/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/uritokencreateselloffer.mdx new file mode 100644 index 0000000..a04c67f --- /dev/null +++ b/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/uritokencreateselloffer.mdx @@ -0,0 +1,47 @@ +--- +title: URITokenCreateSellOffer +description: >- + Uma transação URITokenCreateSellOffer permite que um usuário crie uma oferta de venda + para um URIToken na exchange descentralizada do Xahau. +--- +\[[Fonte](https://github.com/Xahau/xahaud/blob/dev/src/ripple/app/tx/impl/URIToken.cpp)] + +_(Adicionado pela \[emenda URIToken]\[].)_ + +### Exemplo + +```json +{ + "TransactionType": "URITokenCreateSellOffer", + "Account": "rPT1Sjq2YGrBMTttX4GZHjKu9dyfzbpAYe", + "URITokenID": "C1AE6DDDEEC05CF2978C0BAD6FE27362498DGS691DC749DCDD3B95992978C0BA", + "Destination": "rPT1Sjq2YGrBMTttX4GZHjKu9dyfzbpAYe", + "Amount": { + "issuer": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn", + "currency": "USD", + "value": "100", + }, +} +``` + +### Campos + +| Campo | Tipo JSON | \[Tipo Interno]\[] | Descrição | +| ------------- | ------------------------------------------------------------------------------------------------------------------------------------------ | ------------------- | ------------------------------------------------------------------------------------- | +| `Account` | String | AccountID | O endereço da conta que cria a oferta de venda. | +| `URITokenID` | String | Hash256 | O ID do URIToken sendo vendido. | +| `Destination` | String | AccountID | _(Opcional)_ O endereço da conta que receberá a oferta de venda. | +| `Amount` | [Valor em Moeda](/docs/protocol-reference/data-types/currency-formats/#specifying-currency-amounts) | Amount | O valor da moeda que a conta deseja receber em troca do URIToken. | + +### Casos de Erro + +Além dos erros que podem ocorrer em todas as transações, as transações URITokenCreateSellOffer podem resultar nos seguintes códigos de resultado: + +| Código de Erro | Descrição | +| ------------------------ | -------------------------------------------------------------------------------- | +| `tecNO_TARGET` | Ocorre se a conta alvo não existir. | +| `tecNO_PERMISSION` | Ocorre se a conta não tiver permissão para criar uma oferta de venda. | +| `tecINSUF_RESERVE_LINE` | Ocorre se a conta não tiver reserva suficiente para criar uma oferta de venda. | +| `tecINSUF_RESERVE_OFFER` | Ocorre se a conta não tiver reserva suficiente para criar uma oferta de venda. | +| `tecUNFUNDED_OFFER` | Ocorre se a conta não tiver saldo suficiente para criar uma oferta de venda. | +| `tecOFFER_INVALID` | Ocorre se a oferta de venda for inválida. | diff --git a/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/uritokenmint.mdx b/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/uritokenmint.mdx new file mode 100644 index 0000000..c291900 --- /dev/null +++ b/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/uritokenmint.mdx @@ -0,0 +1,59 @@ +--- +title: URITokenMint +description: >- + Uma transação URIToken Mint cunha um novo URIToken e atribui a propriedade à + conta especificada. O URIToken representa um ativo digital único que pode ser + usado em várias aplicações. +--- +\[[Fonte](https://github.com/Xahau/xahaud/blob/dev/src/ripple/app/tx/impl/URIToken.cpp)] + +_(Adicionado pela \[emenda URIToken]\[].)_ + +### Exemplo + +```json +{ + "TransactionType": "URITokenMint", + "Account": "rWYkbWkCeg8dP6rXALnjgZSjjLyih5NXm", + "Flags": 1, + "URI": "697066733A2F2F4445414442454546", + "Digest": "697066733A2F2F4445414442454546697066733A2F2F44454144424545467878", + "Destination": "rPT1Sjq2YGrBMTttX4GZHjKu9dyfzbpAYe", + "Amount": { + "issuer": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn", + "currency": "USD", + "value": "100", + }, +} +``` + +| Campo | Tipo JSON | \[Tipo Interno]\[] | Descrição | +| ------------- | ------------------------------------------------------------------------------------------------------------------------------------------ | ------------------- | --------------------------------------------------------------------------------------------- | +| `Account` | String | AccountID | O endereço da conta que será proprietária do URIToken cunhado. | +| `URI` | String | String | O URI associado ao URIToken cunhado. (máximo de 256 bytes) | +| `Digest` | String | Hash256 | _(Opcional)_ O digest do URIToken. | +| `Destination` | String | AccountID | _(Opcional)_ O endereço da conta que pode comprar o URIToken cunhado. | +| `Amount` | [Valor em Moeda](/docs/protocol-reference/data-types/currency-formats/#specifying-currency-amounts) | Amount | _(Opcional)_ O valor da moeda que a conta deseja receber em troca do URIToken. | + +### Flags de URITokenMint + +Transações do tipo URITokenMint suportam valores adicionais no campo `Flags`, como segue: + +| Nome da Flag | Valor Hex | Valor Decimal | Descrição | +| ------------ | ------------ | ------------- | -------------------------------------------------------------------------------------------------------------------------------------------- | +| `tfBurnable` | `0x00000001` | 1 | Permite que o emissor (ou uma entidade autorizada pelo emissor) destrua o `URIToken` cunhado. (O proprietário do `URIToken` _sempre_ pode fazê-lo.) | + +### Custo Especial de Transação + +A transação URIToken Mint tem um custo de transação padrão, que é o custo mínimo de transação exigido para todas as transações. + +### Casos de Erro + +Além dos erros que podem ocorrer em todas as transações, as transações URIToken Mint podem resultar nos seguintes códigos de resultado: + +| Código de Erro | Descrição | +| ----------------- | --------------------------------------------------------------------------------- | +| `tecDUPLICATE` | Ocorre se um URIToken com o mesmo URI do mesmo emissor já existir. | +| `tecDIR_FULL` | Ocorre se o diretório do proprietário estiver cheio e não puder acomodar o novo URIToken. | +| `temINVALID_FLAG` | Ocorre quando o usuário especificou um `Flag` incorreto. | +| `terNO_ACCOUNT` | Ocorre se a conta remetente não existir. | diff --git a/src/content/docs/br/docs/resources/media-kit.mdx b/src/content/docs/br/docs/resources/media-kit.mdx new file mode 100644 index 0000000..c4f6b53 --- /dev/null +++ b/src/content/docs/br/docs/resources/media-kit.mdx @@ -0,0 +1,5 @@ +--- +title: Kit de Mídia +--- + +Logotipos e diretrizes de identidade visual estão disponíveis em https://github.com/Xahau/Graphics \ No newline at end of file diff --git a/src/content/docs/br/docs/resources/whitepaper.mdx b/src/content/docs/br/docs/resources/whitepaper.mdx new file mode 100644 index 0000000..ad6f6c8 --- /dev/null +++ b/src/content/docs/br/docs/resources/whitepaper.mdx @@ -0,0 +1,193 @@ +--- +title: Whitepaper +--- +import { Aside } from '@astrojs/starlight/components'; + + + + + + +## 1. Resumo + +1. O Xahau Ledger (Xahau) é a sidechain de contratos inteligentes para o ecossistema XRPL. É um fork do código-fonte aberto rippled do XRP Ledger (XRPL) que incorpora todas as funcionalidades úteis e inovadoras do XRPL, incluindo sua sustentabilidade ambiental, mas ajusta e aprimora o código para suportar contratos inteligentes. +2. As principais funcionalidades do Xahau são: + * **Core XRPL:** O Xahau mantém os recursos essenciais que tornaram o XRPL uma das redes mais duradouras e populares, incluindo o **Protocolo de Consenso do XRP Ledger** (anteriormente: Ripple Protocol Consensus Algorithm), a **DEX**, e a lógica de proteger o ledger contra spam e inchaço ao cobrar e queimar taxas no token nativo, mas substitui os recentes **NFTs XLS-20** pelos mais limpos e simples **URITokens**. + * **Hooks para Contratos Inteligentes:** O grande novo recurso do Xahau são os Hooks, a implementação de contratos inteligentes para o rippled. Hooks são pequenos trechos de código instalados em uma conta que impõem regras nas transações que a conta envia ou recebe antes que essas transações possam ser finalizadas. + * **Token Nativo e Melhor Tokenomia:** O Xahau será protegido por seu token nativo, XAH (código de moeda: XAH), e impulsionado por uma tokenomia aprimorada projetada para recompensar validadores e suportar contratos inteligentes. + * **Jogo de Governança do Hook Gênesis:** A conta Gênesis do Xahau é alimentada por um Hook que regula, entre outras coisas, a emissão de novos XAH, e este Hook é governado por um jogo de governança em dois níveis com até 20 validadores de propriedade independente como participantes. +3. Em conjunto, esses recursos criam uma nova rede dentro do ecossistema XRPL que implementa o amendment Hooks para fornecer contratos inteligentes rápidos, baratos e seguros para o ecossistema XRPL, apoiados por uma comunidade devidamente incentivada de validadores e desenvolvedores. +4. O desenvolvimento do Xahau Ledger foi impulsionado pela Xahau Launch Alliance, cinco entidades experientes e comprometidas dentro da comunidade XRPL que assumiram o custo e o risco de estabelecer a nova rede sem um ICO. +5. O Xahau será lançado totalmente funcional e descentralizado com mais de 10 validadores de propriedade independente, administrados por uma mistura representativa do ecossistema XRPL, incluindo desenvolvedores, exchanges e membros de longa data da comunidade. + +## 2. Xahau – Construído a partir do DNA do XRPL + +1. O Xahaud - o software que executa o Xahau - é um fork do rippled, o código-fonte aberto do XRPL. Ele mantém os recursos essenciais que tornaram o XRPL uma das redes mais populares e duradouras desde seu lançamento em 2012. + +### Protocolo de Consenso do XRP Ledger + +2. O Xahau usa o Protocolo de Consenso do XRP Ledger (anteriormente: Ripple Protocol Consensus Algorithm) – às vezes chamado de Prova de Associação (PoA). Ele foi projetado para superar as limitações dos mecanismos de consenso tradicionais, como Prova de Trabalho (PoW) ou Prova de Participação (PoS), particularmente o alto consumo de energia associado ao PoW. +3. O Protocolo de Consenso do XRP Ledger funciona da seguinte forma: + * **Proposta do Validador:** Cada validador propõe um novo conjunto de transações, chamado de "conjunto candidato", que acredita dever ser incluído no próximo ledger. Este conjunto candidato inclui tanto novas transações quanto quaisquer transações que não foram incluídas anteriormente em um ledger validado. + * **Fase de Acordo:** Os validadores se comunicam entre si para trocar e avaliar conjuntos candidatos. Eles verificam de forma independente a validade e a ordem das transações propostas por outros validadores. Por meio de uma série de rodadas iterativas, os validadores tentam convergir para um único conjunto candidato com o qual a maioria concorde. + * **Finalização:** Uma vez que uma supermaioria de validadores (pelo menos 80%) concorda com um conjunto candidato específico, esse conjunto é considerado "finalizado". Os conjuntos candidatos finalizados tornam-se a base para o próximo ledger. + * **Fechamento do Ledger:** O ledger é fechado e um novo ledger é criado com base nas transações do conjunto candidato finalizado. Esse processo ocorre aproximadamente a cada 3 a 5 segundos no XRPL, permitindo tempos de liquidação de transações rápidos. +4. Sob o Protocolo de Consenso do XRP Ledger, cada validador especifica uma UNL (Lista de Nós Únicos), que é uma lista de outros validadores nos quais ele confia. O ledger canônico é encontrado por meio da sobreposição entre as UNLs de todos os validadores. +5. Para facilitar o consenso social sobre a UNL adequada, várias entidades, incluindo a Fundação XRPL, publicam Listas de Validadores (VLs) recomendadas dos validadores que consideram suficientemente confiáveis. Seguir uma dUNL geralmente aceita ajuda a garantir que você permaneça no ledger principal e não acabe inadvertidamente seguindo um fork irrelevante. O Xahau seguirá uma abordagem semelhante, de consenso social, para definir uma dUNL, com organizações como a Fundação XRPL publicando sua VL recomendada. +6. O Protocolo de Consenso do XRP Ledger oferece diversas vantagens, incluindo alta escalabilidade, baixo consumo de energia e resistência à censura e forks de rede. Ao utilizar um conjunto de validadores confiáveis e esse algoritmo de consenso único, o Xahau alcança processamento de transações rápido e seguro, mantendo a descentralização e a confiabilidade. + +### A DEX + +7. O Xahau mantém uma versão da exchange descentralizada (DEX) de livro de ordens limitadas do XRPL, que permite aos usuários negociar e trocar ativos diretamente no ledger. A DEX aproveita a arquitetura descentralizada e sem necessidade de confiança do Xahau para permitir a negociação de ativos ponto a ponto sem a necessidade de intermediários. +8. Em resumo, a exchange descentralizada funciona da seguinte forma: + * **Criação de Ordem:** Os usuários podem criar ordens de compra ou venda na DEX especificando o ativo que desejam negociar, a quantidade desejada e o preço que estão dispostos a aceitar ou pagar. + * **Correspondência de Ordens:** O livro de ordens da DEX mantém um registro de todas as ordens de compra e venda abertas. Quando uma nova ordem é colocada, a DEX a combina automaticamente com as ordens existentes com base no preço e na quantidade. + * **Negociação entre Moedas:** A DEX suporta negociação entre moedas, permitindo que os usuários troquem entre diferentes ativos. Para isso, a DEX usa a moeda nativa do ledger como moeda de ponte, permitindo que os usuários convertam um ativo para a moeda nativa e depois para outro ativo. + * **Função de Busca de Caminho:** A função de busca de caminho é um componente essencial da DEX. Ela ajuda os usuários a encontrar o caminho de negociação mais eficiente ao converter um ativo em outro. Por exemplo, se um usuário deseja trocar o Ativo A pelo Ativo D, mas não há mercado direto disponível, a função de busca de caminho procurará a melhor sequência de negociações (ex.: A para B, B para C e C para D) para alcançar a conversão desejada com mínimo de slippage e taxas. + * **Execução Automática de Ordens:** Uma vez que uma negociação é combinada, a DEX executa automaticamente a transação. O mecanismo de consenso do ledger garante que a transação seja validada e adicionada ao ledger, proporcionando um alto nível de segurança e imutabilidade. + * **Sem Necessidade de Confiança e Descentralizada:** A DEX opera de forma descentralizada e sem necessidade de confiança. Ela não depende de uma exchange centralizada nem exige que os usuários depositem seus fundos em uma carteira de terceiros. Em vez disso, os usuários mantêm o controle sobre seus ativos durante todo o processo de negociação, reduzindo o risco de contraparte. + * **Baixas Taxas e Liquidação Rápida:** Negociar na DEX incorre em taxas mínimas em comparação com exchanges centralizadas tradicionais. O protocolo de consenso do Xahau permite tempos de liquidação rápidos, possibilitando o processamento de transações quase instantâneo. +9. Com esses recursos, a DEX fornece aos usuários uma plataforma conveniente e segura para negociação de tokens ponto a ponto. Ao aproveitar a natureza descentralizada e sem necessidade de confiança do Xahau, a DEX oferece negociação eficiente entre tokens e correspondência de ordens perfeita, mantendo o controle e a privacidade do usuário. + +### Taxas de Transação Queimadas + +10. Para se proteger contra spam e inchaço, o XRPL cobra taxas de transação e reservas de conta em sua moeda nativa e queima todas as taxas de transação, em vez de redistribuí-las para os validadores. O Xahau segue esse modelo de "taxas cobradas e queimadas" para se proteger da mesma forma. +11. Embora seja um mecanismo comprovado para proteger o ledger, isso tem implicações para a tokenomia do Xahau, conforme discutido adiante. As taxas queimadas pelos contratos inteligentes do Xahau, embora ainda pequenas, serão muito maiores e mais variáveis do que as taxas de transação padrão no XRPL. + +### NFTs URIToken em vez de NFTs XLS-20 + +12. Ao contrário do padrão NFT XLS-20 introduzido no XRPL, que depende da compressão de NFTs em "páginas" no ledger, o Xahau usará objetos URIToken. +13. Os URITokens (abreviação de Uniform Resource Identifier Token) são uma forma inovadora de representar e gerenciar NFTs, seus metadados e informações de propriedade dentro do Xahau. Cada token é um objeto de ledger de primeira classe com um endereço único que não muda quando o proprietário atual muda. +14. Os NFTs URIToken têm muitas vantagens sobre o padrão NFT XLS-20, incluindo: + * **Leve e Eficiente:** Os URITokens são objetos de ledger de primeira classe que podem ser criados, destruídos, transferidos, comprados e vendidos, e que interoperam facilmente com os Hooks. A negociação é limitada a uma única oferta de venda por token, que pode ser aceita pelo endereço de destino especificado ou, se nenhum destino for especificado, pelo público em geral. Não há modo intermediado. + * **Interoperabilidade e Imutabilidade:** Os URITokens vêm com um padrão JSON de metadados extensível embutido e um campo Digest opcional (um hash que torna o conteúdo do NFT imutável). Isso fornece flexibilidade para desenvolvedores e criadores escolherem suas soluções de armazenamento preferidas, como IPFS ou servidores web tradicionais. Também promove a interoperabilidade com padrões e plataformas NFT existentes, facilitando a integração com o ecossistema NFT mais amplo. + * **Experiência do Usuário Aprimorada:** Os URITokens podem ser facilmente localizados por seu keylet (endereço no ledger) que não depende do proprietário atual do token. Os metadados e as informações de propriedade do NFT podem ser facilmente acessados e atualizados por meio de protocolos web padrão. Os usuários podem simplesmente clicar no URI associado a um NFT para visualizar seus detalhes, incluindo imagens, descrições e proveniência. Essa abordagem simplifica a experiência do usuário e reduz a complexidade de interagir com NFTs no Xahau. +15. Assim, os URITokens fornecem uma solução leve, flexível e econômica para NFTs no Xahau. + +## 3. Hooks – Contratos Inteligentes para o Ecossistema XRPL + +1. Hooks é uma solução de contratos inteligentes desenvolvida especificamente para o ecossistema XRPL. Os Hooks são pequenos e eficientes trechos de código definidos em uma conta Xahau que executam lógica nas transações enviadas ou recebidas pela conta antes que essas transações sejam finalizadas no ledger. Os Hooks são, portanto, uma forma de os desenvolvedores criarem e implantarem contratos inteligentes no Xahau, abrindo uma ampla gama de possibilidades para aplicações descentralizadas (dApps) e transações automatizadas. +2. O Xahau implementa o amendment Hooks como uma sidechain para que o ecossistema XRPL possa se beneficiar dos Hooks agora, em vez de esperar. Isso também permite que a comunidade XRPL avalie melhor se e como implementar os Hooks no mainnet XRPL no futuro. + +### Benefícios dos Hooks + +3. Alguns benefícios essenciais dos Hooks em relação a outras soluções de contratos inteligentes incluem: + * **Simplicidade e Eficiência:** Os Hooks são leves e eficientes em comparação com soluções convencionais de contratos inteligentes. A arquitetura subjacente do Xahau, que se concentra na liquidação de transações e no consenso rápido, garante a execução rápida de contratos inteligentes sem comprometer o desempenho. + * **Integração Nativa:** Os Hooks são uma solução de contratos inteligentes de camada 1 e, portanto, vivem nativamente dentro do ledger, permitindo que os desenvolvedores criem contratos que interajam diretamente com objetos, saldos e transações no ledger. Em contraste com soluções de contratos inteligentes de camada 2, essa integração estreita simplifica o processo de desenvolvimento e garante interoperabilidade perfeita com o ecossistema do Xahau. + * **Baixas Taxas e Escalabilidade:** Os Hooks aproveitam as baixas taxas de transação e a alta escalabilidade do Xahau. Como a maioria das blockchains, o Xahau pode lidar com um alto volume de transações por segundo, tornando-o adequado para aplicações que exigem execução de contratos inteligentes rápida e econômica. + * **Segurança e Confiabilidade:** Os Hooks herdam a robusta segurança e confiabilidade do XRPL. O Protocolo de Consenso do XRP Ledger, que alimenta o Xahau, garante uma rede descentralizada com consenso entre validadores confiáveis. Esta sólida base de segurança proporciona confiança tanto para desenvolvedores quanto para usuários. + * **Compatibilidade com o Ecossistema:** Os Hooks são projetados para ser compatíveis com as ferramentas e serviços XRPL existentes, facilitando a integração de contratos inteligentes nas aplicações dos desenvolvedores. Essa compatibilidade permite interação perfeita com outros recursos do XRPL, como exchanges descentralizadas e canais de pagamento. + * **Descentralização de Conta:** Usando Hooks, é possível que uma conta Xahau seja totalmente autônoma e emita e receba transações de acordo com a lógica de seu Hook, em vez de depender de detentores externos de chaves privadas para autorizar transações manualmente. + +### Exemplos de Casos de Uso + +4. Ao introduzir capacidades de contratos inteligentes no ecossistema XRPL, os Hooks oferecem uma solução poderosa e eficiente para desenvolvedores que buscam criar aplicações descentralizadas e automatizar transações. Exemplos dos tipos de funções que os Hooks podem realizar incluem: + * **Listas Brancas:** Uma conta habilitada com Hook pode proteger contas contra fraudes ou transações sancionadas, sendo codificada para aceitar ou enviar transações apenas para contas na lista branca. + * **Listas Negras:** Uma conta habilitada com Hook pode ser codificada para se recusar a receber ou enviar transações para qualquer conta proibida (na lista negra). + * **Escrow Sofisticado:** Uma conta habilitada com Hook pode reter qualquer ativo recebido de uma conta indicada e apenas encaminhar ou devolver esses ativos se instruída a fazê-lo por uma transação válida que atenda a critérios predeterminados. + * **Registro Automatizado:** Uma conta habilitada com Hook pode atuar como um registro automatizado e emitir e resgatar URI NFTs como evidência de registro ou direitos de registro. + * **Tesouro Soberano:** Moedas emitidas podem imitar ativos descentralizados e sem contraparte sendo depositadas em uma Conta de propriedade própria com um Hook que emite a moeda de acordo com um cronograma de emissão divulgado e predeterminado. +5. A combinação de simplicidade, baixas taxas, escalabilidade, segurança e compatibilidade com o ecossistema significa que o Xahau oferece acesso antecipado a uma solução de contratos inteligentes atrativa para o ecossistema XRPL. A experiência do Xahau com Hooks ajudará a comunidade a determinar se e como implementar os Hooks no XRPL no futuro. + +## 4. XAH – Token Nativo e Tokenomia + +1. O Xahau é protegido por seu token nativo, XAH. Seus detalhes relevantes são os seguintes: + * **Token Nativo:** XAH + * **Ticker:** XAH + * **Menor Unidade:** 1 drop ou 0,000001 XAH + * **Função:** O XAH é a moeda da rede. É um token utilitário para adquirir serviços de rede. Como no XRPL, as transações no Xahau incorrem em uma taxa ou reserva cobrada em XAH para proteger o Ledger contra spam e inchaço. + * **Liquidez Inicial:** 600 milhões distribuídos aos participantes do lançamento. + * **Oferta Máxima:** Sem limite. + * **Mecanismos de Emissão:** O fornecimento de XAH é determinado pelos amendments habilitados no protocolo de consenso do Xahau: + * **Ajuste Mensal de Saldo:** Para recolocar em circulação parte do XAH queimado das taxas de transação, cada usuário ativo pode reivindicar um aumento em seu saldo de conta de ~0,34% de seu saldo médio mensal (equivalente a 4% ao ano composto). Essa emissão é controlada pelo Jogo de Governança do Protocolo, que usa uma combinação dos amendments Hooks, BalanceRewards e XahauGenesis. + * **Recompensas Mensais de Assento:** Para recolocar em circulação parte do XAH queimado das taxas de transação, e para incentivar uma governança ativa e adequada, um valor equivalente ao total dos Ajustes Mensais de Saldo reivindicados também é recompensado aos validadores do Jogo de Governança. + +### Distribuição Inicial + +2. As partes do lançamento investiram tempo e recursos significativos para lançar o Xahau. Uma distribuição inicial é fornecida no nível do protocolo pelo amendment XahauGenesis. +3. O protocolo pagará um modesto total de 600 milhões de XAH da seguinte forma: 12 milhões para cada um dos oito Assentos de validadores do Jogo de Governança no lançamento. + * 16 milhões adicionais para a GateHub para inicialização de liquidez de stablecoin na DEX. + * 160 milhões adicionais para a XRPL Labs (Xaman) por Propriedade Intelectual — a Xaman assumiu o principal ônus técnico e financeiro do desenvolvimento dos Hooks e do xahaud. Essa distribuição adicional é por esse esforço. + * 328 milhões para a Fundação XRPL (agora INFTF), para ajudar a garantir a saúde do ecossistema do Protocolo XRPL (agora Xahau) no futuro. + +### Ajuste Mensal de Saldo + +4. Um desafio que o Xahau deve gerenciar é o custo adicional dos contratos inteligentes em comparação com as transações normais do XRPL. +5. No XRPL, as taxas de transação custam apenas um drop ou 0,000001 XRP. Contra um fornecimento total de 100 bilhões de XRP, esse é um custo trivial, mas suficiente. As transações de Hooks, por outro lado, podem custar ordens de magnitude a mais para configurar e acionar. Além disso, embora cada transação XRPL seja padronizada, os Hooks podem variar enormemente em sua complexidade e custo. Para se proteger adequadamente contra spam e inchaço de seus Hooks, o Ledger deve cobrar de forma apropriada (e dinâmica) pelo tamanho e pela complexidade lógica de cada transação de Hook. +6. A consequência é que, como uma cadeia de contratos inteligentes que queima taxas, o XAH poderia facilmente ser queimado até próximo de zero, e certamente muito mais rapidamente do que o XRP equivalente seria queimado no XRPL, levando potencialmente a incentivos perversos para acumular Xahau em vez de usá-lo para implantar e executar Hooks. +7. Para se proteger contra esses riscos, o Xahau precisa de um mecanismo a nível de protocolo que recoloque os tokens queimados em circulação, mas que não simplesmente incentive taxas altas. É para isso que serve o ajuste mensal de saldo. +8. O Ajuste Mensal de Saldo funciona da seguinte forma: + * A cada mês, cada conta Xahau pode optar por reivindicar (contra o protocolo) um ajuste baseado em seu saldo médio de XAH (calculado desde o último ajuste). O valor ajustado equivale a 4% ao ano composto (aproximadamente 0,34% por mês). + * Os usuários podem reivindicar seu ajuste de saldo enviando uma transação RewardClaim para a conta Gênesis a qualquer momento, desde que 30 dias tenham passado desde a última reivindicação. Fazer isso demonstra que são usuários ativos. + * Ao receber a transação de reivindicação, o protocolo, por meio dos amendments BalanceRewards e XahauGenesis, aumenta o saldo da conta do usuário pelo valor do ajuste. + * Ajustes de saldo não reivindicados são perdidos como penalidade por inatividade. + * 4% é a taxa inicial no lançamento, mas pode ser alterada pelo Jogo de Governança se se mostrar pequena ou grande demais no futuro. +9. Esse mecanismo permite que usuários ativos reivindiquem um ajuste mensal que coloca mais XAH em circulação, mitigando o risco de o token ser queimado até zero pelas taxas de execução de contratos inteligentes. + +### Recompensas Mensais de Validadores de Governança + +10. A Conta Gênesis do Xahau está habilitada com um Hook que controla, entre outras coisas, a emissão de XAH. Este Hook precisa de um arranjo de governança para que possa ser monitorado, alterado e/ou substituído diante de condições de rede e do mundo real em mudança. +11. É bem sabido que os validadores do mainnet XRPL não recebem nenhum tipo de recompensa pelos serviços que prestam ao sustentar o Ledger principal. No entanto, a infraestrutura custa dinheiro para ser executada, e a experiência do mundo real mostra que essa falta de incentivo leva a uma falta de validadores ativamente gerenciados. +12. O Hook Gênesis do Xahau precisa saber, ou ser informado, quais contas ele deve confiar ao decidir se deve se atualizar. Portanto, essas contas devem ser conhecidas com antecedência, em vez de emergir das UNLs sobrepostas. +13. A solução técnica para esse problema é um Jogo de Governança de Hook Gênesis incentivado que recompensa certos Validadores por supervisionar o Hook. Funciona da seguinte forma: + * Há 20 "Assentos" no Jogo de Governança do Hook Gênesis. + * Cada Assento é controlado por uma única Conta Xahau (Nível 1) ou por um comitê autogerenciado de 3 a 20 Contas (Nível 2). + * Para cada Assento ocupado, o protocolo emite e distribui 1/20 do total dos Ajustes Mensais de Saldo reivindicados naquele mês. + * Se um Assento for mantido por um comitê de Contas, as recompensas desse Assento são divididas de acordo com a escolha desse comitê. + * Se nenhum usuário reivindicar um Ajuste de Saldo naquele mês, nenhuma recompensa é paga a nenhum validador. + * A cada Flag Ledger (256 ledgers), um registro no ledger chamado UNLReport é gerado. Este relatório contém uma lista de chaves públicas de validadores que 80% dos outros validadores acreditam ter participado adequadamente do consenso desde o Flag Ledger anterior. O Hook Gênesis só distribuirá recompensas de validadores para Assentos que correspondam às chaves públicas dos validadores no UNLReport. +14. Assim, o Jogo de Governança do Hook Gênesis inclui um mecanismo de recompensa projetado para garantir que as contas confiáveis sejam recompensadas por executar validadores confiáveis, que essas recompensas estejam vinculadas à atividade do usuário, e que essas recompensas coloquem novo XAH em distribuição, mitigando o risco de uma crise de liquidez de token decorrente de altas taxas de execução de contratos inteligentes. + +## 5. Jogo de Governança do Xahau + +1. As cadeias do Protocolo de Consenso do XRP Ledger dependem de uma robusta sobreposição nas UNLs dos validadores para definir o ledger canônico. Se um validador não confia em máquinas suficientes que todos os outros confiam, ele corre o risco de seguir inadvertidamente um fork irrelevante do ledger. Determinar a melhor UNL é uma questão de consenso social (fora da cadeia). +2. Para auxiliar esse consenso social, várias entidades publicam dUNLs – listas de validadores que todos devem seguir. O Xahau seguirá a mesma abordagem, com a Fundação XRPL e outros esperados para publicar tais listas. Portanto, como o XRPL, o Xahau será uma cadeia pública sem permissão para a qual qualquer pessoa pode executar um validador. E como o XRPL, qualquer atualização do protocolo dependerá do suporte de mais de 80% dos validadores da UNL às mudanças, da mesma forma que no XRPL. +3. Embora a dUNL ajude a definir os validadores responsáveis pelo Ledger canônico, o Xahau tem um segundo desafio de governança, não presente no mainnet XRPL: a governança de seu Hook Gênesis. O mainnet XRPL emitiu todo o seu XRP na criação. O Xahau não pode seguir essa abordagem. Seu token nativo precisa ser emitido em resposta à ocorrência de eventos predefinidos (ou seja, Burn2Mint, Ajustes de Conta, Recompensas de Validadores). Ele usa um Hook em sua Conta Gênesis para conseguir isso. +4. Isso significa que o Xahau precisa de um mecanismo de governança para seu Hook Gênesis, caso o Hook precise ser ajustado ou substituído. Isso é conhecido como o Jogo de Governança: + * **Propósito:** O Jogo de Governança existe para garantir que os validadores da UNL permaneçam ativos e permite que esses membros ativos mantenham o Hook na conta Gênesis que controla a distribuição de XAH. + * **Assentos:** Há 20 Assentos em uma mesa. Um Assento é uma Conta Xahau cujo voto conta no Jogo de Governança. + * **Mesa L1:** O Jogo de Governança requer pelo menos a mesa de nível superior. Isso é chamado de mesa de Nível 1 (Mesa L1). Esta mesa por definição existe apenas na conta Gênesis de acordo com o Hook do Jogo de Governança instalado lá. Um assento na mesa L1 pode ser preenchido por uma Conta ou pode estar vazio. Esses assentos são chamados de L1s. + * **Mesa L2:** Um assento L1 pode ser preenchido por uma Conta que possui outro Hook de Governança diferente instalado. Os assentos nesta mesa são chamados de L2s, e a mesa é uma Mesa L2. A estrutura é um comitê autogerenciado de 3 a 20 Contas que controlam coletivamente o assento L1 e seus direitos de voto. Assim, até 400 Contas podem estar envolvidas no jogo de Governança de dois níveis, dependendo da combinação de Assentos L1 e L2. + * **Preenchimento de Assentos:** Os Assentos L1 são preenchidos ou esvaziados por votação de 80% de todos os Assentos L1 preenchidos existentes. Para os Assentos L2, o comitê de Contas que coletivamente detém esse Assento L1 convida ou desconvida novos membros (até um máximo de 20 e um mínimo de 3) por maioria de votos, ou de acordo com qualquer outra lógica ou regras que considerem adequadas. Nenhum outro Assento tem qualquer controle sobre os membros de uma Mesa L2. + * **Votação:** Cada Assento L1 tem 1 voto no Jogo de Governança. Para os Assentos L2, o único voto de sua mesa L2 é determinado pela lógica que essa mesa L2 decidir. O padrão é mais de 50% de votação dos membros do Assento L2 nessa mesa L2. + * **Mudanças de Hook:** Todas as mudanças no Hook são votadas por meio do Jogo de Governança. Uma mudança de Hook só é bem-sucedida se apoiada pela porcentagem definida de votos de todos os Assentos. O voto regular é de 80%, mas para o aumento da taxa de ajuste de saldo é de 100%. + * **Recompensas:** Para incentivar os Assentos L1 a executar validadores confiáveis, os Assentos L1 ganham Recompensas mensais desde que participem ativamente do consenso. + * **Base da dUNL:** Os validadores executados pelos participantes do Jogo de Governança do Hook Gênesis devem formar a base de qualquer dUNL, pois qualquer Assento que se comporte de forma não confiável corre o risco de ser votado para fora pelos outros Assentos. +5. Os diferentes tipos de Assentos permitem uma maior diversidade de Contas participantes sem comprometer a segurança. Os Assentos de Nível 1 são adequados para Contas controladas por entidades significativas em que a comunidade pode confiar, enquanto os Assentos de Nível 2 permitem um pool mais amplo de participantes, mas como sua participação coletiva conta como 1 voto, seus números não superam a confiança depositada nos Assentos de Nível 1. +6. Assim, o Jogo de Governança permite que até 400 Contas participem e recompensa essas Contas por fazê-lo, desde que também participem do consenso executando um validador confiável. + +## 6. A Aliança de Lançamento do Xahau + +1. O Xahau foi desenvolvido por uma aliança de 5 entidades independentes com histórico comprovado de desenvolvimento e suporte ao ecossistema XRPL. Essas entidades são as seguintes: + * XRPL Labs (Xaman), o desenvolvedor de software por trás da carteira XUMM, dos Hooks e do Xahaud, que assumiu a maior parte da expertise e do custo do desenvolvimento do Xahau. + * GateHub Limited, uma empresa de tecnologia multinacional, exchange de criptomoedas e provedora de serviços de criptoativos, incluindo Stablecoins emitidas no XRPL. + * Titanium OU, uma empresa de consultoria e infraestrutura de TI especializada em hospedagem segura e um grande fornecedor de infraestrutura para o XRPL (como Alloy Networks). + * Evernode Labs Ltd, o desenvolvedor do projeto de contratos inteligentes Evernode e responsável por implantá-lo no Xahau. + * Digital Governing OU, uma entidade incorporada associada a uma empresa globalmente ativa de serviços de contabilidade, auditoria e jurídico. + +## 7. Lançamento Totalmente Funcional e Descentralizado + +1. O Xahau será lançado totalmente funcional e descentralizado sem levantar fundos. Sem Controle Centralizado. +2. O Xahau será lançado com 8 de seus 20 Assentos do Jogo de Governança preenchidos: + * 5 serão Assentos de Nível 1, cada um preenchido por um membro da Aliança de Lançamento do Xahau. + * 3 serão Mesas de Nível 2, uma das quais será preenchida por um comitê de Exchanges e a outra por um comitê diverso de projetos da comunidade XRP, desenvolvedores e apoiadores de longa data. + * 1 será a FYEO, uma empresa que oferece serviços de auditoria e revisão de código em desenvolvimento de blockchain, incluindo software como Hooks. + +### Sem Captação de Recursos + +3. Não há ICO e nenhum recurso está sendo captado no lançamento. +4. Os membros da Aliança Xahau financiaram de forma independente seus próprios esforços de desenvolvimento. Não há financiamento comunitário, nem qualquer agrupamento de dinheiro ou recursos para o desenvolvimento futuro do Xahau. Tampouco há um roadmap, uma "Fundação Xahau" ou outro tesouro centralizado. Qualquer desenvolvimento futuro fica inteiramente a critério de atores independentes dentro do ecossistema. + +### Sem Promessas + +5. Os membros do Jogo de Governança são entidades independentes. Não há acordo, arranjo ou entendimento entre eles sobre como votar, implantar seus recursos ou usar seus ativos, incluindo qualquer XAH. É apenas a lógica do Jogo — ser um Validador confiável aos olhos dos outros membros ou ser votado para fora do Jogo — que orienta o comportamento do Validador. Esta é uma característica inerente do mecanismo do Protocolo de Consenso do XRP Ledger (PoA) que o Xahau utiliza. + +### Sem Necessidade de Funcionalidades Adicionais + +6. Embora o software, por sua natureza, precise ser mantido, não há funcionalidades essenciais faltando no Xahaud ou que necessitem de desenvolvimento adicional para que o software seja útil como sidechain de contratos inteligentes do XRPL. diff --git a/src/content/docs/br/docs/support/help-us.mdx b/src/content/docs/br/docs/support/help-us.mdx new file mode 100644 index 0000000..43bf297 --- /dev/null +++ b/src/content/docs/br/docs/support/help-us.mdx @@ -0,0 +1,11 @@ +--- +title: Ajude-nos +--- + +A documentação do Xahau é open source e está aberta para contribuições [no GitHub](https://github.com/Xahau/xahau-web). + +Muitas lacunas e detalhes não cobertos são esperados na documentação, por isso convidamos **todos** a colaborar para elevá-la ao padrão desejado. + +Se você encontrar algo faltando, [crie uma issue](https://github.com/Xahau/xahau-web/issues) no repositório ou vá em frente e crie um pull request para a branch principal com as alterações sugeridas ou a documentação atualizada. + +Se você quiser contribuir, mas não souber por onde começar, pode sempre consultar o [quadro de projetos no GitHub](https://github.com/orgs/Xahau/projects/2/views/1), onde as issues estão organizadas. Se você não estiver familiarizado com o GitHub, o [Discord da Comunidade](https://discord.com/invite/UzU58haAn4) é um ótimo lugar para obter ajuda e se envolver. \ No newline at end of file diff --git a/src/content/docs/br/docs/what-is-different.mdx b/src/content/docs/br/docs/what-is-different.mdx new file mode 100644 index 0000000..25a12d1 --- /dev/null +++ b/src/content/docs/br/docs/what-is-different.mdx @@ -0,0 +1,81 @@ +--- +title: 'XRPL/Xahau: O que é Diferente?' +description: Uma lista das principais diferenças entre o XRP Ledger e o Xahau. +--- +import { Aside, LinkCard } from '@astrojs/starlight/components'; + +#### Escrow de Token IOU & PayChannels + +O Xahau introduz o Escrow de Token IOU e os PayChannels como funcionalidades exclusivas, aumentando a flexibilidade e a segurança das transações. Eles facilitam a retenção temporária de tokens IOU sob condições predefinidas (escrow) e o estabelecimento de canais de pagamento para transações eficientes fora do ledger. + + + +#### URITokens, NÃO NFTokens + +Em vez de usar NFTokens como o XRPL, o Xahau emprega URITokens. Os URITokens são uma forma de ativos digitais não fungíveis com identificadores únicos e metadados, oferecendo uma abordagem inovadora para a representação de ativos na blockchain. + + + +#### Repositório Diferente + +O Xahau e o XRPL operam a partir de repositórios diferentes, o que indica que são protocolos separados com suas próprias trajetórias de desenvolvimento e documentação. Essa distinção implica que o Xahau pode oferecer funcionalidades e otimizações únicas não encontradas no XRPL. + +[https://github.com/Xahau/xahaud](https://github.com/Xahau/xahaud) + +#### Processo de Build Diferente (WASM & LLVM) + +O processo de build do Xahau incorpora WebAssembly (WASM) e a Máquina Virtual de Baixo Nível (LLVM), o que não está descrito no processo de build do XRPL. O Xahau utiliza essas tecnologias para aprimorar as capacidades de contratos inteligentes e melhorar o desempenho e a compatibilidade entre plataformas de sua base de código. + + + +#### Prazo de Amendment Diferente (5 dias) + +O processo de amendment no Xahau tem um prazo especificado de 5 dias, diferindo do cronograma do XRPL. Os amendments são mudanças de protocolo, e o período de 5 dias refere-se à duração que os validadores têm para chegar a um consenso e implementar essas mudanças. + + + +#### Sequência Inicial Diferente + +O Xahau emprega uma sequência inicial diferente para contas em relação ao XRPL. A sequência inicial na conta é o tempo de época do Ripple quando a conta foi criada/importada para o Xahau. + +#### Import / Burn 2 Mint + +Importar do XRPL para o Xahau concede aos usuários 2 tokens XAH, indicando um mecanismo de incentivo para encorajar a migração de ativos ou a ponte do XRPL para o Xahau, potencialmente para aumentar a adoção da rede e a liquidez. + + + +#### Recompensas de Saldo (Recompensas por usar XAH) + +O Xahau oferece recompensas de saldo pela utilização do XAH, uma funcionalidade ausente no XRPL. Este é um sistema de recompensa por manter ou usar o token nativo do Xahau, XAH, para promover o engajamento e a estabilidade da rede. + + + +#### Hooks + +Os Hooks no Xahau, que não estão presentes no XRPL, são scripts programáveis ou funções semelhantes a contratos inteligentes que podem ser anexados a contas. Eles adicionam uma camada de programabilidade e automação às operações da rede. + + + +#### Estrutura de Governança + +A estrutura de governança do Xahau difere da do XRPL. O Xahau tem sua própria abordagem para tomada de decisões, sistemas de proposta ou papéis de validadores, o que pode influenciar a evolução da rede. + + + +#### Requisitos de Nó + +Executar um nó Xahau tem requisitos diferentes em comparação a um nó XRPL. Essas diferenças estão relacionadas às especificações técnicas necessárias para suportar as funcionalidades únicas e as demandas de rede do Xahau. + + + +#### Token Nativo + +O token nativo do Xahau é o XAH, distinto do XRP do XRPL. Como a moeda principal dentro da rede Xahau, o XAH serve como o principal meio de troca e reserva de valor, central para o quadro econômico da rede. + + + +#### Versionamento (Usa Datas) + +O Xahau emprega um sistema de versionamento baseado em datas, diferente da abordagem de versionamento do XRPL. Esse método pode fornecer uma maneira mais intuitiva de acompanhar as atualizações e o desenvolvimento histórico da rede. + + diff --git a/src/i18n/fraudReportTranslations.ts b/src/i18n/fraudReportTranslations.ts index c1214ac..3adc198 100644 --- a/src/i18n/fraudReportTranslations.ts +++ b/src/i18n/fraudReportTranslations.ts @@ -1,4 +1,4 @@ -export type FraudReportLocale = 'en' | 'es' | 'ja' +export type FraudReportLocale = 'en' | 'es' | 'ja' | 'br' export type FraudReportTranslations = { frontmatter: { @@ -371,4 +371,106 @@ export const fraudReportTranslations: Record< 'ネットワークエラー: サーバーに接続できませんでした。接続を確認して再度お試しください。', }, }, + 'br': { + frontmatter: { + title: 'Reportar Fraude', + description: + 'Você foi vítima de um golpe ou hack? Aqui está o que fazer!', + }, + intro: { + body: 'Xahau é uma blockchain pública, sem uma parte governante que possa congelar ou recuperar fundos, fechar contas ou impedir as pessoas de acessar seus ativos.', + warning: 'Não podemos reverter ou cancelar transações, ninguém pode.', + lead: 'Podemos marcar contas usadas para atividades ilícitas, o que irá:', + bullets: [ + 'Ser incluída em nossa API que exchanges e outras entidades estão usando para conformidade AML para monitorar depósitos, e possivelmente reter fundos ilícitos.', + 'O movimento de fundos será rastreado automaticamente e receberemos notificações sempre que eles se moverem, não importa quão antigo seja o caso.', + 'Em caso de golpe, avisar outros usuários através do software de carteira e exchanges usando nossa API, para não enviar fundos para uma conta marcada.', + ], + steps: [ + { + title: '1. Envie o endereço para o Xahau Forensics', + body: 'Mantemos o maior registro de endereços fraudulentos no Xahau e ele é usado por várias entidades para combater atividades ilícitas.', + }, + { + title: '2. Reporte seu caso às autoridades', + body: 'Reporte à polícia local e se seu país tiver um formulário de relatório online para crimes cibernéticos ou crimes financeiros, reporte lá também.', + }, + { + title: '3. Acompanhe seu relatório policial', + body: 'Trabalhamos com as autoridades. Deixe-os saber que temos as informações. As chances são de que também estamos em contato com outras vítimas e podemos ajudar as autoridades a combinar casos entre jurisdições e fornecer inteligência acionável.', + }, + ], + expectationTitle: 'O que você pode esperar?', + expectations: [ + 'Não podemos reverter ou cancelar transações, ninguém pode.', + 'Fazemos o nosso melhor para que os fundos sejam apreendidos quando saírem do Xahau, trabalhando com exchanges e outras rampas de saída através de nossa API de registro de endereços fraudulentos e por contato manual.', + 'Quando você nos reporta uma conta, pode esperar que tratemos seu relatório com tanta atenção quanto qualquer outro relatório.', + 'Recebemos muitos relatórios todos os dias. Se uma conta for adicionada ao nosso registro de endereços fraudulentos, estamos cuidando dela da melhor forma possível junto com todos os outros casos.', + 'Se dinheiro for apreendido, entraremos em contato com você, se você nos deixou uma maneira de entrar em contato.', + 'Para recuperar fundos, você precisa trabalhar com as autoridades para a papelada.', + ], + expectationWarning: + 'Monitoramos centenas de casos ao mesmo tempo e não podemos seguir cada caso individualmente. Só entraremos em contato com você se tivermos boas notícias!', + }, + form: { + successTitle: 'Sucesso!', + successBody: 'Obrigado por seu relatório. Ele foi enviado com sucesso.', + reportIdLabel: 'ID do Relatório:', + reportIdFallback: 'desconecido', + errorTitle: 'Erro', + addressLabel: 'Endereço Xahau', + addressPlaceholder: 'rXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX', + addressHint: + 'Digite o endereço Xahau associado à atividade fraudulenta', + descriptionLabel: 'Descrição', + descriptionPlaceholder: 'Descreva a atividade fraudulenta', + descriptionHint: + 'Forneça o máximo de detalhes possível para nos ajudar a investigar', + urlLabel: 'URL', + urlPlaceholder: 'URL opcional relacionada à fraude', + urlHint: + 'Forneça uma URL se relevante, por exemplo, um site de golpe ou postagem em mídia social', + categoryLabel: 'Categoria Sugerida', + categoryPlaceholder: 'Selecione uma categoria...', + categoryOptions: [ + { value: 'giveaway', label: 'Sorteio' }, + { value: 'theft', label: 'Roubo' }, + { value: 'other', label: 'Outro' }, + ], + categoryHint: 'Ajude-nos a categorizar o tipo de fraude', + contactLabel: 'Informações de Contato', + contactPlaceholder: + 'Informações de contato opcionais, por exemplo, e-mail, X handle ou nome de usuário do Telegram', + contactHint: + 'Forneça informações de contato se estiver disposto a ajudar com perguntas de acompanhamento', + requiredFields: 'Campos obrigatórios', + submitLabel: 'Enviar Relatório', + submitAnotherLabel: 'Enviar Outro Relatório', + optional: 'Opcional', + }, + privacy: { + title: 'Privacidade e Segurança', + bullets: [ + "Este formulário usa ALTCHA, um CAPTCHA compatível com a privacidade que não rastreia você", + 'Seu relatório é enviado com segurança para a rede Xahau Forensics', + 'Os relatórios são revisados e usados para melhorar a segurança da rede', + 'Nenhuma informação pessoal é necessária para enviar um relatório', + ], + }, + attribution: { + prefix: 'Xahau Forensics é operado por ', + label: 'INFTF', + suffix: '.', + }, + messages: { + captchaIncomplete: + 'Por favor, complete a verificação CAPTCHA antes de enviar.', + captchaFailed: + 'Falha na verificação CAPTCHA. Por favor, complete o desafio e tente novamente.', + submitting: 'Enviando...', + submitFailed: 'Falha ao enviar o relatório. Por favor, tente novamente.', + networkError: + 'Erro de rede: Não foi possível conectar ao servidor. Por favor, verifique sua conexão e tente novamente.', + }, + }, } diff --git a/src/i18n/indexTranslations.ts b/src/i18n/indexTranslations.ts index bc87306..9600686 100644 --- a/src/i18n/indexTranslations.ts +++ b/src/i18n/indexTranslations.ts @@ -102,6 +102,39 @@ export const indexTranslations = { stats_ledgers: '閉鎖済みレジャー', stats_node_cta: 'ノードを運営したいですか？', }, + 'br': { // Placeholder translations for Portuguese (Brazil) + hero_title: 'A Blockchain Mais Inteligente com Programabilidade Baseada em Contas', + hero_subtitle: + 'Não apenas contratos inteligentes – contas inteligentes. Barato e rápido por design. Construído para o mundo real.', + hero_learn: 'Aprenda o básico', + hero_docs: 'Ver documentação', + network_title: 'A Rede Xahau', + network_subtitle: 'Por que Xahau é a blockchain certa para o seu negócio?', + feat1_title: '1. Hooks de Contrato Inteligente', + feat1_desc: + 'Xahau suporta contratos inteligentes leves diretamente nas contas, permitindo lógica automática para aprovações, rejeições ou comportamento personalizado sem exigir que os usuários chamem um contrato.', + feat2_title: '2. Baixas Taxas com Queima de Taxas', + feat2_desc: + 'Xahau oferece custos de transação previsíveis e baixos. Uma parte de cada taxa é queimada, reduzindo spam e alinhando incentivos com a saúde a longo prazo da rede.', + feat3_title: '3. Governança Pronta para Empresas', + feat3_desc: + 'Com governança estruturada e coordenação de validadores, Xahau fornece um ambiente estável para uso regulado e empresarial, incluindo cadeia de suprimentos, pagamentos e aplicações de conformidade.', + feat4_title: '4. Rápido, Verde e Escalável', + feat4_desc: + 'Com um protocolo de consenso eficiente, Xahau processa transações rapidamente sem mineração—ideal para empresas que precisam de desempenho e sustentabilidade.', + feat5_title: '5. Controle de Tokens e Ativos por Design', + feat5_desc: + 'As empresas podem emitir ativos ou tokens com controle detalhado sobre como eles são usados ou transferidos, aplicando regras automaticamente no nível do livro-razão.', + feat_more: 'Descubra mais recursos', + stats_title: 'Estatísticas da rede', + stats_subtitle: 'Xahau em números', + stats_accounts: 'Contas', + stats_hooks: 'Hooks instalados', + stats_nodes: 'Nós', + stats_txs: 'Transações/24h', + stats_ledgers: 'Livros-razão fechados', + stats_node_cta: 'Quer executar um nó?', + }, } export type IndexLocale = keyof typeof indexTranslations diff --git a/src/pages/br/about.mdx b/src/pages/br/about.mdx new file mode 100644 index 0000000..49c831f --- /dev/null +++ b/src/pages/br/about.mdx @@ -0,0 +1,57 @@ +--- +title: Sobre Xahau +description: O que é Xahau? Uma explicação pequena +--- + +import PageLayout from "../../layouts/PageLayout.astro"; +import PageSection from "../../components/PageSection.astro"; + + + +
+ +
+ + +A Xahau é uma blockchain de camada 1 (L1) com uma combinação única de recursos e uma nova abordagem para programabilidade em blockchain, também conhecida como contratos inteligentes. + +A tecnologia, já comprovada ao longo do tempo, liquida transações em cerca de 4 segundos, com custos muito baixos — chegando a frações de centavo de dólar. É escalável, suportando atualmente até 10.000 transações por ledger, além de ser inerentemente sustentável e energeticamente eficiente. + +A Xahau oferece recursos nativos para emissão e negociação de moedas em sua exchange descentralizada integrada, NFTs nativos e diversas possibilidades para DeFi por meio de lógica personalizada com seus contratos inteligentes, chamados Hooks. + +Os Hooks ficam associados às contas, trazendo uma abordagem diferente para lógica customizada baseada em eventos de conta, como o recebimento de transações. Atualmente, Hooks são desenvolvidos em C, mas o suporte a JavaScript já foi desenvolvido e está em fase de testes, com outras linguagens também previstas. Isso torna os contratos inteligentes mais acessíveis para milhões de desenvolvedores, sem uma curva de aprendizado tão acentuada. + + + +### Qual é a tecnologia por trás da Xahau? + +A Xahau é uma evolução do código do XRP Ledger, aprimorada com contratos inteligentes, programabilidade baseada em contas (Hooks) e suporte igualitário para moedas emitidas em recursos nativos, como escrows e payment channels. + +Assim como a XRPL, a Xahau utiliza um mecanismo de consenso federado. As transações são confirmadas por um protocolo em que servidores independentes, chamados validadores, entram em consenso sobre a ordem e o resultado das transações. Todos os servidores processam cada transação segundo as mesmas regras, e qualquer transação válida é confirmada rapidamente. Todas as transações são públicas e transparentes, e qualquer pessoa pode operar um validador. + +A Xahau também introduz um modelo de governança comunitária para decisões da rede. Nesse sistema de duas camadas, os participantes votam em temas como assentos, Hooks e recompensas. + + + +## XAH: a moeda nativa da Xahau + +A moeda nativa da rede é o XAH, uma moeda inflacionária. Toda conta pode participar do ajuste de saldo ao interagir com um Hook na conta gênese, acumulando mensalmente 4% sobre o saldo. + +O XAH é usado para evitar spam na rede, adicionando um custo às transações. Transações comuns custam frações de XAH, enquanto interações com Hooks têm custo maior. O XAH também é necessário como reserva bloqueada para possuir contas, objetos ou armazenar dados consumidos por contratos inteligentes. + +Como os Hooks aumentam a taxa de queima de XAH em relação à XRPL, projetos que dependem dessa lógica customizada devem manter saldo suficiente para gerar ajuste mensal e cobrir taxas. + + + +## Principais eventos da Xahau + +A Xahau foi lançada em 30 de outubro de 2023 pela Xahau Launch Alliance, uma aliança temporária formada por desenvolvedores e organizações experientes do ecossistema XRPL: XRPL Labs, GateHub Limited, Titanium OU, Evernode Labs Ltd e Digital Governing OU. + +No primeiro ano, a rede recebeu várias atualizações, como o recurso nativo Remit (em março de 2024), melhorias de desempenho, nós que operam apenas em memória e suporte a Hooks em JavaScript. + +Também houve o lançamento de um serviço de remessas internacionais em parceria com a Inclusive Financial Technologies Foundation e o Cooperative Bank of Oromia, um dos maiores bancos da Etiópia. A solução permite que pessoas no exterior enviem valores em EUR digital via blockchain com liquidação quase instantânea e baixo custo para familiares na Etiópia em ETB. + +Além disso, a fundação firmou um memorando com a African Union para apoiar o Fundo da Paz da União Africana com uma plataforma de doações em múltiplas moedas baseada na Xahau. + + + diff --git a/src/pages/br/connect.mdx b/src/pages/br/connect.mdx new file mode 100644 index 0000000..f07a0d0 --- /dev/null +++ b/src/pages/br/connect.mdx @@ -0,0 +1,210 @@ +--- +title: Xahau Connect +description: Eventos profissionais de blockchain para discussão séria e inovação +--- + +import PageLayout from "../../layouts/PageLayout.astro"; +import PageSection from "../../components/PageSection.astro"; + + + +## Próximos Eventos + +### Curso de Programação em Blockchain Non-EVM + +
+
+ 📅 Data e Horário: Sexta-feira, 27 de fevereiro de 2026, às + 16h00 CET +
+
+ 📍 Local: MIL (Madrid Innovation Lab) +
+ Calle Bravo Murillo 37-39 +
+ Madri, Espanha +
+ + Ver no Google Maps + +
+
+ 🎟️ Inscrição: Inscreva-se para participar presencialmente + por meio deste [formulário](https://luma.com/hiy3lsdq) +
+
+ +Junte-se a nós para um curso introdutório gratuito sobre programação em blockchain Xahau, desenvolvido para ajudá-lo a dar seus primeiros passos nesse tipo de tecnologia. Este curso presencial de 4 horas foca no aprendizado de conceitos e ferramentas fundamentais por meio de exercícios práticos. Seja você um desenvolvedor curioso sobre alternativas Non-EVM, um empreendedor ou alguém sem experiência prévia em blockchain, o curso abordará tópicos desde arquitetura básica e criação de carteiras até contratos inteligentes em ambientes Non-EVM. Idioma: Espanhol e Inglês. + + + +## Eventos Anteriores + +### Custódia Institucional de Criptoativos e Tokenização de Ouro + +
+
+ 📅 Data e Horário: Quarta-feira, 11 de fevereiro de 2026, + às 18h30 CET +
+
+ 📍 Local: MIL (Madrid Innovation Lab) +
+ Calle Bravo Murillo 37-39 +
+ Madri, Espanha +
+ + Ver no Google Maps + +
+
+ 🎤 Palestrantes em Destaque: +
+
+ • José Ángel Fernández – CEO, Prosegur Crypto +
+
+
+
+ 📺 Sessão Gravada: Assista online no{" "} + + YouTube do Madrid Innovation Lab + +
+
+ +Uma sessão presencial do Xahau Connect com José Ángel Fernández, CEO da Prosegur Crypto. A palestra explorou a jornada da Prosegur no ecossistema blockchain por meio da Prosegur Crypto, abordando a custódia institucional de criptoativos, como esses sistemas funcionam do ponto de vista tecnológico e de segurança, e os serviços oferecidos a clientes institucionais. A sessão também tratou da oferta de tokenização de ouro da Prosegur Crypto, discutindo tanto a implementação técnica quanto o modelo de negócio por trás da tokenização do ouro físico e seus casos de uso no mundo real. + +### Blockchain e Regulação: A Europa Sob Escrutínio Legal + +
+
+ 📅 Data e Horário: Quinta-feira, 4 de dezembro de 2025, às + 18h30 CET +
+
+ 📍 Local: MIL (Madrid Innovation Lab) +
+ Calle Bravo Murillo 37-39 +
+ Madri, Espanha +
+ + Ver no Google Maps + +
+
+ 🎤 Palestrantes em Destaque: +
+
+ • Horacio Gómez Rey – Head of Legal Espanha, N26 +
+
+ • Pedro Méndez de Vigo – AVP Legal Europa, Crypto.com +
+
+
+
+ 📺 Sessão Gravada: Assista online no{" "} + + YouTube do Madrid Innovation Lab + +
+
+ +Uma discussão aprofundada sobre regulação de blockchain na Europa, com especialistas jurídicos de destaque de grandes empresas de fintech e cripto. A sessão explorou o cenário regulatório em evolução, os desafios de conformidade e o futuro do blockchain sob o escrutínio legal europeu. + + + +## Sobre o Xahau Connect + +O **Xahau Connect** é uma série de eventos profissionais de blockchain criada pela [**INFTF**](https://www.inftf.org) (Inclusive Financial Technology Foundation) para fomentar discussões sérias e agnósticas sobre tecnologia blockchain e suas aplicações no mundo real. + +Os eventos reúnem especialistas, desenvolvedores profissionais, pesquisadores e inovadores de diversos ecossistemas blockchain para compartilhar conhecimento, explorar desafios e colaborar no avanço da tecnologia além do hype e da especulação. + +## Nossa Missão + +No Xahau Connect, focamos em: + +
+
+ • Discussão Técnica Séria: Conversas aprofundadas sobre + arquitetura blockchain, negócios, oportunidades, regulação, inovação e muito + mais. +
+
+ • Agnosticismo em Blockchain: Acolhendo perspectivas de + todos os ecossistemas e tecnologias blockchain. +
+
+ • Networking Profissional: Conectando desenvolvedores, + especialistas, pesquisadores e líderes do setor. +
+
+ • Aplicações no Mundo Real: Foco em implementações práticas + e casos de uso que impulsionam a adoção. +
+
+ • Compartilhamento de Conhecimento: Aprendendo com + especialistas de diferentes domínios e setores da blockchain. +
+
+ +## Quem Deve Participar + +Os eventos do Xahau Connect são voltados para: + +
+
• Desenvolvedores e Builders de Blockchain que trabalham em protocolos, contratos inteligentes, dApps e infraestrutura.
+
• Arquitetos Técnicos que projetam soluções e integrações em blockchain.
+
• Pesquisadores e Acadêmicos explorando teoria de blockchain, criptografia e sistemas distribuídos.
+
• Líderes Empresariais avaliando blockchain para aplicações de negócios.
+
• Contribuidores do Ecossistema que desenvolvem ferramentas, documentação e recursos comunitários.
+
• Profissionais do Setor aplicando blockchain em finanças, cadeia de suprimentos, identidade e outros setores. Se você leva a tecnologia e seu potencial a sério, o Xahau Connect é para você.
+
+ + +## Palestrantes, Patrocinadores e Contato + +### Participe + +
+
+ • Propostas de Palestra e Consultas sobre Patrocínio:{" "} + connect@xahau.org +
+
+ +Somos gratos aos nossos parceiros que apoiam a missão do Xahau Connect de fomentar o discurso profissional sobre blockchain. Os detalhes de parceiros e palestrantes serão anunciados à medida que confirmamos a participação para os próximos eventos. + +### Inscreva-se para Atualizações + +Para receber notificações sobre os próximos eventos do Xahau Connect: + +
+
• Siga @XahauNetwork e INFTF no X
+
• Envie um e-mail para connect@xahau.org
+
+ + diff --git a/src/pages/br/contest.mdx b/src/pages/br/contest.mdx new file mode 100644 index 0000000..ed566cc --- /dev/null +++ b/src/pages/br/contest.mdx @@ -0,0 +1,251 @@ +--- +title: Xahau Dev Contest +description: Ecosystem Rising - Construa serviços voltados ao usuário com a Xahau +--- + +import PageLayout from "../../layouts/PageLayout.astro"; +import PageSection from "../../components/PageSection.astro"; + + + +## Introdução + +Bem-vindo ao **Xahau Dev Contest: Ecosystem Rising**! +Este concurso convida inovadores a construírem **serviços voltados ao usuário com a Xahau** e a competirem por prêmios enquanto fortalecem o ecossistema Xahau. + +## Prêmios + +- **3 prêmios principais em XAH** para os projetos vencedores. + - **🥇 1º Lugar** valor de 4000 USD em XAH. + - **🥈 2º Lugar** valor de 2000 USD em XAH. + - **🥉 3º Lugar** valor de 1000 USD em XAH. + +## Cronograma + +- **Prazo de submissão:** 1º de fevereiro de 2026. +- **Painel de juízes:** 5 membros da comunidade Xahau e XRPL (veja abaixo). + + + + +## Painel de Juízes + +O concurso será avaliado por **cinco membros da comunidade**: + +- • [**tequ**](https://x.com/_tequ_) – Desenvolvedor Blockchain Xahau +- • [**Robert Kiuru**](https://x.com/robertkiuru) – COO, _XRPL Labs_ +- • **[gadget78](https://x.com/gadget78)** – Desenvolvedor Evernode +- • [**Andrei Rosseti**](https://x.com/andreirosseti) – Arquiteto do Xahau DocProof | CTO, _EleveCRM_ +- • [**Vet**](https://x.com/Vet_X0) – Contribuidor da Comunidade XRPL + +## Tema: Serviços na Xahau + +Os participantes devem construir **serviços baseados na web que interajam com a Xahau (Mainnet)** e sejam projetados para o **usuário final**, seja usuários casuais, usuários avançados, setor público ou setor privado. + +Exemplos incluem **(mas não se limitam a)**: + +
+
+ • Ferramentas para o usuário cotidiano: +
+
◦ Painéis de finanças pessoais
+
◦ Gerenciadores de carteiras
+
◦ Aplicativos comunitários
+
+
+
+ • Serviços empresariais: +
+
◦ Portais de pagamento
+
◦ Plataformas de fidelidade
+
◦ Ferramentas de atendimento ao cliente
+
+
+
+ • Plataformas públicas: +
+
◦ Marketplaces de NFT
+
◦ Sistemas de votação
+
◦ Hubs de doação
+
◦ Aplicativos culturais
+
◦ Utilitários para o bem social
+
+
+
+ + +## Regras de Participação + +
+
• Você pode submeter quantos projetos quiser.
+
• Cada projeto pode ser submetido por um indivíduo ou um grupo de participantes.
+
• Projetos diferentes do(s) mesmo(s) participante(s) podem ser elegíveis para prêmios diferentes.
+
• Os projetos devem funcionar na Xahau Mainnet.
+
+
• Cada projeto deve estar acessível online, para que tanto os juízes quanto o público possam usá-lo ou visualizá-lo.
+
◦ Isso evita que os juízes precisem instalar ou configurar os projetos localmente, e reduz o risco de erros inesperados ou a necessidade de assistência do participante.
+
+
+
• Cada submissão deve incluir documentação básica para ajudar outros a entenderem o projeto.
+
◦ Opcionalmente, você também pode incluir material multimídia (vídeos, slides, demos, etc.) para explicar melhor seu trabalho.
+
+
• Ferramentas de IA podem ser usadas tanto para desenvolvimento quanto para documentação.
+
• Se o seu projeto usar Hooks, o código do Hook deve ser de código aberto, para que possa ser auditado por segurança e servir como recurso de aprendizado para a comunidade. Você deve anexar o código C na sua submissão juntamente com o hash do hook. Consulte a seção "Formato de Submissão".
+
• Projetos que claramente oferecem serviços financeiros regulados ou que visam atividades ilegais não são elegíveis.
+
• Para ser avaliado pelos juízes, você deve incluir sua submissão com um PR conforme indicado na seção "Formato de Submissão".
+
• Após a criação do seu PR de submissão, publique um tweet no X sobre seu projeto, marcando @XahauNetwork, para anunciar sua participação no Xahau Dev Contest.
+
+ + +## Critérios de Avaliação + +Ao revisar as submissões, os juízes valorizarão especialmente: + +
+
• Originalidade e criatividade da ideia.
+
• Ausência de concorrentes existentes oferecendo o mesmo serviço na Xahau Mainnet antes do concurso.
+
• Impacto e utilidade para os usuários finais (indivíduos, empresas ou setor público).
+
• Qualidade de execução (estabilidade, documentação, experiência do usuário).
+
• Uso de Hooks (Contratos Inteligentes na Xahau).
+
+ + +## Formato de Submissão + +Cada projeto deve incluir uma pasta e pelo menos um **arquivo de submissão** dentro do diretório de submissões do **[repositório](https://github.com/xahau/xahau-2nd-dev-contest)**. +O arquivo e o diretório devem ter o nome do seu usuário do GitHub seguido do nome do projeto, separados por um underscore, usando a extensão .md para o arquivo. + +Exemplo: submissions/NomeGitHub_NomeProjeto/NomeGitHub_NomeProjeto.md + +O arquivo deve conter os seguintes campos: + +
+
+ • Título do Projeto +
+
+ • Breve Descrição +
+
+ • Participantes (nomes ou apelidos) +
+
+ • Redes Sociais dos Participantes +
+
+ • E-mail de Contato +
+
+ • Link para o Projeto Online +
+
+ • Endereço Xahau para receber o prêmio em caso de vitória +
+
+ • Link para a Documentação +
+
+ • Código dos Hooks em C e hash correspondente (caso seu + projeto use um ou mais, para confirmar que é seguro, adicione os arquivos .c + na pasta da sua submissão) +
+
+ • Conta Hooks do projeto (para confirmar que você está + usando os hooks previamente fornecidos para este projeto) +
+
+ • Link para o Repositório do Projeto (opcional) +
+
+ • Outros Links (opcional, ex.: vídeo demo, apresentação, + slides) +
+
+ +Um diretório e arquivo de modelo estão disponíveis na pasta do repositório, que os participantes podem usar para preencher os detalhes do seu projeto. + + + +## Suporte e Comunidade + +Se tiver dúvidas ou precisar de orientação: + +- Entre no **[Discord dos Xahau Builders](https://discord.gg/ds7nb93mYj)**. +- Ou envie um e-mail para **[contests@xahau.org](mailto:contests@xahau.org)**. + +Tentaremos responder o mais rápido possível. Suas perguntas também podem ser adicionadas ao FAQ neste README para que outros se beneficiem das respostas. + +## Propriedade + +- Todos os projetos submetidos permanecem **propriedade de seus criadores originais**. + +## Links Úteis + +Aqui estão alguns recursos úteis para desenvolvedores Xahau: + +- [Documentação Xahau](https://docs.xahau.network) +- [Documentação de Hooks Xahau](https://xahau.network/docs/hooks/) +- [Repositórios GitHub da Xahau](https://github.com/Xahau) +- [Website Xaman](https://xaman.app) +- [Faucet da Testnet Xahau](https://xahau-test.net/) +- [Discord Xahau](https://discord.gg/ds7nb93mYj) + +## Resumo: O Que Você Precisa Fazer + +
+
• Inspire-se. Seja criativo e motivado para construir algo que fortaleça o ecossistema Xahau.
+
• Construa seu projeto. Desenvolva seu serviço baseado na web usando a Xahau Mainnet.
+
• Submeta seu trabalho. Crie um PR (Pull Request) seguindo as instruções na seção "Formato de Submissão".
+
• Anuncie sua participação. Publique um tweet no X sobre seu projeto, marcando @XahauNetwork, e compartilhe que você participou do Xahau Dev Contest.
+
+ + +## FAQ + +**P: Posso submeter mais de um projeto?** + +- R: Sim! Você pode submeter quantos quiser, individualmente ou em grupo. + +**P: Os projetos precisam ser de código aberto?** + +- R: Não, mas devem incluir pelo menos documentação básica para que os juízes entendam como funcionam. Se o seu projeto incluir Hooks, você deve anexar o código C na sua submissão junto com o hash do hook. Consulte a seção "Formato de Submissão". + +**P: Posso usar IA para me ajudar a construir ou documentar meu projeto?** + +- R: Sim, o uso de IA é totalmente permitido. + +**P: Que tipo de serviços vocês esperam?** + +- R: Qualquer serviço que ofereça **valor aos usuários finais** — sejam indivíduos, empresas ou o setor público. Desde marketplaces de NFT e painéis financeiros até sistemas de votação, aplicativos de pagamento, hubs de doação ou qualquer serviço inovador público/privado. + +**P: Há vantagem em usar Hooks?** + +- R: Sim, projetos que implementam criativamente **Hooks (contratos inteligentes na Xahau)** receberão reconhecimento especial. + +**P: O que acontece com meu projeto após o concurso?** + +- R: Você mantém a propriedade total. + +**P: Onde posso fazer perguntas?** + +- R: No **[Discord da Comunidade Xahau](https://discord.gg/ds7nb93mYj)** ou enviando um e-mail para **[contests@xahau.org](mailto:contests@xahau.org)**. + + + + +## Aviso Final + +Ao participar, você concorda com o seguinte: + +
+
• Os participantes devem atender aos critérios de elegibilidade e seguir todas as regras. Não é permitido submeter projetos que já foram publicados antes da competição.
+
• Os projetos permanecem propriedade de seus criadores, mas os organizadores reservam o direito de exibir, compartilhar ou destacar as submissões com o devido crédito.
+
• Os organizadores reservam o direito de desqualificar submissões que violem as regras ou comprometam a integridade do concurso. Todas as decisões do júri são finais e não estão sujeitas a recurso.
+
• Os organizadores não são responsáveis por danos, despesas ou perdas durante a participação. Os organizadores também reservam o direito de modificar os requisitos do concurso a qualquer momento, se necessário.
+
• Você reconhece que sanções e certas restrições jurisdicionais podem se aplicar. A elegibilidade para receber recompensas pode exigir conformidade com as leis aplicáveis, incluindo a conclusão da verificação KYC (Conheça Seu Cliente).
+
• Todos os impostos, taxas ou outras obrigações financeiras relacionadas às recompensas são de responsabilidade exclusiva dos participantes.
+
• Se tiver dúvidas ou incertezas sobre elegibilidade, requisitos ou obrigações fiscais, entre em contato conosco pelos canais de comunicação fornecidos antes de submeter sua inscrição.
+
Agora é sua vez: **Construa, submeta e mostre sua inovação com a blockchain Xahau!**
+
+ + diff --git a/src/pages/br/ecosystem.mdx b/src/pages/br/ecosystem.mdx new file mode 100644 index 0000000..a892a50 --- /dev/null +++ b/src/pages/br/ecosystem.mdx @@ -0,0 +1,172 @@ +--- +layout: ../../layouts/PageLayout.astro +title: Ecossistema +description: Xahau ao redor do mundo +--- + +import EcosystemButton from "../../components/EcosystemButton.astro"; +import gatehub from "../../assets/ecosystem-logos/gatehub.png"; +import bitrue from "../../assets/ecosystem-logos/bitrue.png"; +import bithomp from "../../assets/ecosystem-logos/bithomp.png"; +import xahscan from "../../assets/ecosystem-logos/xahscan.png"; +import xahau_services from "../../assets/ecosystem-logos/xahau-services.png"; +import xrplwin from "../../assets/ecosystem-logos/xrplwin.png"; +import xaman from "../../assets/ecosystem-logos/xaman.png"; +import dcent from "../../assets/ecosystem-logos/dcent.png"; +import bitmart from "../../assets/ecosystem-logos/bitmart.png"; +import coinex from "../../assets/ecosystem-logos/coinex.png"; + +## Carteiras + +
+ + + + +
+ +## Corretoras + +
+ + + + +
+ +## Exploradores e utilitários + +
+ + + + +
+ +## Projetos + +
+ + + + + + + + + + + + + + + + + + +
diff --git a/src/pages/br/features.mdx b/src/pages/br/features.mdx new file mode 100644 index 0000000..41e3a9b --- /dev/null +++ b/src/pages/br/features.mdx @@ -0,0 +1,96 @@ +--- +title: Recursos +description: Tecnologia comprovada com uma abordagem inovadora +--- + +import PageLayout from "../../layouts/PageLayout.astro"; +import PageSection from "../../components/PageSection.astro"; + + + +## Hooks: Lógica de Contrato Inteligente no Nível da Conta + +A 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 incorporados diretamente nas contas dos usuários. Esses Hooks podem automaticamente inspecionar, modificar ou rejeitar qualquer transação envolvendo aquela conta, sem necessidade de chamadas de função explícitas. + +Por serem executados de forma inline e dentro do consenso, os Hooks oferecem programabilidade em tempo real com sobrecarga mínima. 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 das transações. + +## Controle de Tokens e Ativos por Design + +A Xahau oferece a emissores e usuários **controle granular sobre tokens e trustlines**. Funcionalidades como `TrustSet`, `Clawback`, `Freeze` e `Deposit Authorization` permitem personalização total de como os tokens podem ser usados ou recebidos. Ativos podem ser permitidos, bloqueados ou queimados, tudo aplicado no nível do protocolo. + +Isso torna a Xahau excepcionalmente adequada para instrumentos financeiros regulados, stablecoins, programas de fidelidade ou cadeias de suprimento corporativas — qualquer cenário onde conformidade, segurança e precisão são essenciais. + + + +## Governance Game: Coordenação Descentralizada com Propósito + +A Xahau conta com um sistema de governança inovador sustentado pelo **Governance Game**, um mecanismo transparente e on-ledger para propor, revisar e votar em emendas. Os operadores de validadores (Governadores) participam diretamente na moldagem do protocolo, enquanto competem em um sistema estruturado de recompensas baseado em responsabilidade e engajamento. + +Esse 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 transformar a governança em um jogo seguro e alinhado a incentivos, a Xahau estabelece um novo padrão para coordenação on-chain. + +## Balance Rewards: Rendimento Passivo Sem Staking + +A Xahau oferece um sistema de **Balance Rewards** que permite às contas acumular valor passivamente apenas por manterem ativos. Essas recompensas são calculadas com base no saldo da conta e distribuídas por um mecanismo garantido pelo consenso, sem exigir staking, delegação ou contratos de terceiros. + +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 de sistemas de yield farming ou staking em outras blockchains, o modelo de recompensas da Xahau não exige que os usuários bloqueiem ativos ou persigam estratégias complexas de DeFi — funciona nativamente, com transparência e simplicidade. + + + +## Escrow: Transferências Condicionais para Qualquer Ativo + +A Xahau suporta **escrow on-ledger** de tokens nativos e **emitidos**, possibilitando 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 em condições, aplicada pela própria rede. + +Seja construindo um sistema de pagamento baseado em marcos, liquidação em marketplace ou distribuição confiável de tokens, os escrows da Xahau oferecem uma ferramenta simples e poderosa — sem necessidade de contratos inteligentes externos. O suporte nativo tanto para ativos fungíveis quanto não fungíveis em escrow torna esse um recurso excepcionalmente versátil. + +## Remit: Transferências Nativas Entre Contas + +O recurso **Remit** permite transações simplificadas e com múltiplas operações 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 mudanças de saldo de forma atômica. + +Isso melhora a eficiência e a confiabilidade, especialmente para processadores de pagamento, marketplaces ou aplicações que precisam realizar operações agrupadas. Por estar integrado ao protocolo, o Remit garante desempenho previsível, baixa latência e forte auditabilidade. + + + +## Taxas Baixas com Queima de Taxas + +A 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 da rede a longo prazo. 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. + +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 no estilo de leilão, a Xahau oferece previsibilidade e alinhamento econômico para todos os usuários. + +## Rápida, Verde e Escalável + +Construída sobre uma versão aprimorada do protocolo de consenso do XRPL, a 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 servir casos de uso financeiros e empresariais do mundo real sem comprometer o meio ambiente ou a experiência do usuário. + +A arquitetura da 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. + + + +## URITokens: NFTs Nativos na Xahau + +Os **URITokens** representam a abordagem da Xahau para tokens não fungíveis (NFTs), implementados como parte nativa do ledger em vez de via contratos inteligentes separados. Um URIToken é um objeto de primeira classe no ledger, identificado exclusivamente pela conta emissora e por um Identificador Uniforme de Recursos (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. + +Esse padrão NFT integrado significa que criadores podem mintar, negociar ou queimar 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, oferecendo flexibilidade no gerenciamento de NFTs. Ao integrar NFTs no nível do protocolo, a Xahau torna a emissão e o gerenciamento de colecionáveis digitais ou credenciais mais eficientes e seguros. + +## Offers: Exchange Descentralizada (DEX) Integrada + +A Xahau inclui um sistema nativo de **Offers**, que alimenta uma exchange descentralizada integrada no 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. + +Esse recurso, herdado do DEX do XRPL, permite um ambiente de negociação dinâmico e responsivo onde a troca de valor acontece ponto a ponto sem exchanges intermediárias. A capacidade de colocar e cancelar ordens de negociação é fornecida por transações dedicadas (OfferCreate e OfferCancel). Ao contrário de muitas blockchains que exigem contratos inteligentes ou plataformas externas para negociação, o DEX da Xahau é um recurso de primeira classe do ledger. Essa exchange on-ledger oferece liquidação rápida e taxas baixas, tornando a negociação de ativos transparente para usuários e aplicações. + + + +## Checks: Sistema de Pagamento Diferido + +A Xahau suporta **Checks**, um sistema de pagamento diferido semelhante a escrever cheques digitais na blockchain. Uma parte pode emitir um Check (promessa de pagamento) que o destinatário pretendido pode sacar em um momento posterior 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á reivindicar quando determinadas condições forem atendidas. + +O ledger possui transações dedicadas para criar um cheque, sacá-lo ou cancelá-lo. Poucas outras plataformas têm esse tipo de instrumento de pagamento diferido nativo; o sistema de cheques da Xahau fornece uma camada extra de controle de pagamento, tudo aplicado pelas regras da rede sem necessidade de contratos inteligentes personalizados. + +## Payments: Transferências Multi-Ativo e Canais + +A funcionalidade de **Payments** na Xahau foi projetada para facilitar transferências de valor rápidas e flexíveis em toda a rede. De forma única, a Xahau (assim como o XRPL) suporta _pagamentos multi-ativo_ por meio de um sistema de trust lines e moedas emitidas. Usando uma transação `TrustSet`, duas partes podem estabelecer uma trust line para transacionar em um ativo personalizado ou IOU, permitindo suporte integrado a múltiplas moedas ou tokens sem necessidade de contratos inteligentes. + +Isso significa que empresas podem emitir stablecoins ou tokens na Xahau e os usuários podem enviá-los ou trocá-los nativamente. O conjunto de Payments também inclui recursos avançados como **Deposit Preauthorization**, que permite a uma conta criar uma lista de permissões de quem pode lhe enviar fundos, adicionando segurança contra transações indesejadas. + +Além disso, a 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 então liquidem o resultado líquido na blockchain. Com transações como PaymentChannelCreate, Fund e Claim, a Xahau viabiliza micropagamentos ou pagamentos em streaming que são garantidos pelo ledger sem congestioná-lo. + + + diff --git a/src/pages/br/fraud-report.astro b/src/pages/br/fraud-report.astro new file mode 100644 index 0000000..5f5308d --- /dev/null +++ b/src/pages/br/fraud-report.astro @@ -0,0 +1,5 @@ +--- + import FraudReportPage from '../../components/FraudReportPage.astro' + import { fraudReportTranslations } from '../../i18n/fraudReportTranslations' +--- + diff --git a/src/pages/br/index.mdx b/src/pages/br/index.mdx new file mode 100644 index 0000000..88bca13 --- /dev/null +++ b/src/pages/br/index.mdx @@ -0,0 +1,3 @@ +--- +layout: ../../layouts/IndexLayout.astro +--- diff --git a/src/pages/br/privacy-policy.mdx b/src/pages/br/privacy-policy.mdx new file mode 100644 index 0000000..c068933 --- /dev/null +++ b/src/pages/br/privacy-policy.mdx @@ -0,0 +1,105 @@ +--- +layout: ../../layouts/PageLayout.astro +title: Política de Privacidade +description: Política de Privacidade do xahau.network +--- + +# Política de Privacidade + +_Última atualização: 1º de julho de 2025_ + +Esta Política de Privacidade explica como coletamos, usamos e protegemos seus dados pessoais quando você visita o [xahau.network](https://xahau.network). Estamos comprometidos em cumprir o Regulamento Geral de Proteção de Dados (RGPD) e respeitar seus direitos. + +## 1. Quem Somos + +O website xahau.network é operado por: + +**INFTF MTU** +Número de registro: 80586600 +Endereço: Ringtee 15, Kuressaare, Estônia 93815 +E-mail: [info@inftf.org](mailto:info@inftf.org) + +A INFTF MTU é a controladora de dados deste website. + +## 2. Dados que Coletamos + +Podemos coletar as seguintes categorias de dados pessoais: + +- **Dados de uso** (ex.: páginas visitadas, tempo gasto no site) +- **Dados de análise** (ex.: endereço IP, tipo de navegador, informações do dispositivo) + +**Não** coletamos identificadores pessoais como seu nome ou endereço de e-mail, a menos que você os forneça ativamente. + +## 3. Como Coletamos Dados + +Coletamos dados usando: + +- **Cookies e tecnologias similares** + (Você é solicitado a consentir com isso na sua primeira visita ao site.) + +- **Ferramentas de análise de terceiros** + (Essas ferramentas podem coletar informações de uso para fins estatísticos e de segurança.) + +## 4. Finalidade do Tratamento de Dados + +Usamos os dados coletados para os seguintes fins: + +- **Análise**: Para entender e melhorar como nosso website é utilizado. +- **Segurança**: Para detectar e prevenir abusos ou atividades maliciosas. + +## 5. Base Legal para o Tratamento + +Tratamos seus dados com base nas seguintes bases legais: + +- **Consentimento**: Para análise e cookies não essenciais. +- **Interesses legítimos**: Para garantir a segurança e a integridade do nosso website. + +## 6. Cookies e Tecnologias de Rastreamento + +Utilizamos cookies para coletar análises e melhorar o desempenho do website. Quando você visita nosso site, um banner permite que você escolha aceitar ou recusar cookies não essenciais. + +Para mais informações, consulte nossa [Política de Cookies](/privacy-policy) (link a ser adicionado). + +## 7. Compartilhamento de Dados + +**Não** compartilhamos seus dados pessoais com terceiros. + +## 8. Retenção de Dados + +Retemos dados de análise por até **12 meses**, após os quais são excluídos ou anonimizados. + +## 9. Transferências de Dados para Fora da UE + +**Não** transferimos dados pessoais para fora da União Europeia. + +## 10. Seus Direitos sob o RGPD + +Você tem o direito de: + +- Acessar seus dados pessoais +- Solicitar a correção de dados imprecisos +- Solicitar a exclusão de seus dados +- Opor-se ao tratamento ou restringi-lo +- Retirar o consentimento a qualquer momento (quando o tratamento for baseado em consentimento) +- Registrar uma reclamação junto a uma autoridade supervisora + +Para exercer seus direitos, entre em contato conosco pelo e-mail [info@inftf.org](mailto:info@inftf.org). + +## 11. Restrições de Idade + +Nosso website não se destina especificamente a crianças, mas não impõe restrição de idade. + +## 12. Autoridade Supervisora + +Você tem o direito de registrar uma reclamação junto à Inspeção de Proteção de Dados da Estônia: + +**Andmekaitse Inspektsioon** +Website: [https://www.aki.ee](https://www.aki.ee) +Telefone: +372 627 4135 +E-mail: [info@aki.ee](mailto:info@aki.ee) + +## 13. Atualizações desta Política + +Podemos atualizar esta política periodicamente. A versão mais recente estará sempre disponível nesta página, e a data da última atualização será indicada no início. + +Para qualquer dúvida sobre esta Política de Privacidade, entre em contato conosco pelo e-mail [info@inftf.org](mailto:info@inftf.org). diff --git a/src/pages/br/roadmap.mdx b/src/pages/br/roadmap.mdx new file mode 100644 index 0000000..71f2eb0 --- /dev/null +++ b/src/pages/br/roadmap.mdx @@ -0,0 +1,70 @@ +--- +title: Roadmap +description: Este ano, a Xahau Network pretende receber atualizações poderosas em escalabilidade, acessibilidade, segurança e inovação +--- + +import PageLayout from "../../layouts/PageLayout.astro"; +import PageSection from "../../components/PageSection.astro"; +import roadmap from "../../assets/roadmap_2025.jpeg"; +import { Image } from "astro:assets"; + + + +Xahau roadmap 2025 + +# 1º Semestre de 2025 + +## 1. Projeto "L10K" + +Melhorar a eficiência da tecnologia central para aumentar a capacidade de transações para 10.000 transações por ledger, com mais eficiência e segurança. + +Um marco de desempenho para o ecossistema Xahau! + +## 2. Melhoria do Monitoramento UDP e RPC + +Recursos de monitoramento sem conexão e RPC para operadores de nós otimizam o desempenho e a escalabilidade em toda a rede. + +Permitindo monitoramento eficiente e passivo de ambientes com um ou múltiplos nós — reduzindo significativamente a sobrecarga. + +## 3. Finalização de Novos Recursos (Remarks, Touch, Blackhole, DataMonitor) + +Concluir o desenvolvimento e a integração desses recursos de ponta, melhorando a interação com a Xahau tanto para desenvolvedores quanto para usuários finais por meio de produtos criados pelos desenvolvedores. + +## 4. Suporte Completo à Hardware Wallet Ledger para Xahau + +Garantir transações seguras e simplificadas na Xahau com compatibilidade com a Hardware Wallet Ledger, ampliando a acessibilidade à Xahau em todo o mundo. + +## 5. Acesso a Exchanges e Plataformas On/Off-Ramp + +A Xahau pretende se tornar mais acessível por meio de exchanges e plataformas on/off-ramp, apoiando uma participação e integração mais amplas no ecossistema. + +## 6. Suporte ao LedgerLive + +Integração da Xahau com o Ledger Live, permitindo fácil acesso e gerenciamento usando o popular produto Ledger Live. + +## 7. Frame Universal Embeddable de Explicação de Hooks + +Permitindo que qualquer carteira integre facilmente uma explicação clara da influência dos Hooks nas transações (web, mobile, desktop), com visuais claros e integrados para transações HookSet, garantindo uma adoção mais fácil. + +# 2º Semestre de 2025 + +## 8. Implementação de Hooks em JavaScript + +Pendente de aprovação de auditoria, levar Hooks baseados em JavaScript e suas ferramentas a dezenas de milhões de desenvolvedores ao redor do mundo para desenvolver usando a Xahau para lógica on-chain avançada e capacidades de transações programáveis. + +## 9. Auditorias Abrangentes e Verificações de Segurança + +Concluir auditorias de todos os principais recursos de 2025 para demonstrar a segurança e a estabilidade da rede, oferecendo garantias verificáveis ao mundo à medida que avançamos para 2026. + +## 10. Melhoria da Experiência do Usuário + +Orientado por feedback, o ecossistema Xahau garantirá integração e usabilidade perfeitas em todas as carteiras e aplicações. + +## 11. Implementação de Batch + +Viabilizar verificações eficientes de múltiplas transações, garantindo que todas ou nenhuma das transações ocorram, enquanto permite que provedores de serviços incorporem operações específicas de fluxo de trabalho de forma transparente no fluxo de transações. + +**2025 é o ano em que a Xahau se torna mais fácil de acessar, usar, aproveitar e construir, enquanto escala de forma mais inteligente, rápida e robusta.** + + + diff --git a/src/plugins/remarkGlobalReferences.ts b/src/plugins/remarkGlobalReferences.ts index 04fe936..38e0e39 100644 --- a/src/plugins/remarkGlobalReferences.ts +++ b/src/plugins/remarkGlobalReferences.ts @@ -5,55 +5,55 @@ const parseRules: { path: string parse: (content: string) => { label: string; url: string }[] }[] = [ - { - path: 'src/content/references/global.md', - parse: (content: string) => { - const lines = content.split('\n') - const result: { label: string; url: string }[] = [] - for (const line of lines) { - const match = line.match(/^\[([^\]]+)\]:\s*(.+)$/) - if (match) { - const [, label, url] = match - result.push({ label, url: url.trim() }) + { + path: 'src/content/references/global.md', + parse: (content: string) => { + const lines = content.split('\n') + const result: { label: string; url: string }[] = [] + for (const line of lines) { + const match = line.match(/^\[([^\]]+)\]:\s*(.+)$/) + if (match) { + const [, label, url] = match + result.push({ label, url: url.trim() }) + } } - } - return result + return result + }, }, - }, - { - path: 'src/content/references/transactions.md', - parse: (content: string) => { - const lines = content.split('\n') - const result: { label: string; url: string }[] = [] - for (const line of lines) { - if (line.startsWith('//')) continue - if (line.length > 0) { - const url = `/docs/protocol-reference/transactions/transaction-types/${line.toLowerCase()}` - result.push({ label: `${line}`, url }) - result.push({ label: `${line} transaction`, url }) - result.push({ label: `${line} transactions`, url }) + { + path: 'src/content/references/transactions.md', + parse: (content: string) => { + const lines = content.split('\n') + const result: { label: string; url: string }[] = [] + for (const line of lines) { + if (line.startsWith('//')) continue + if (line.length > 0) { + const url = `/docs/protocol-reference/transactions/transaction-types/${line.toLowerCase()}` + result.push({ label: `${line}`, url }) + result.push({ label: `${line} transaction`, url }) + result.push({ label: `${line} transactions`, url }) + } } - } - return result + return result + }, }, - }, - { - path: 'src/content/references/pseudo-transactions.md', - parse: (content: string) => { - const lines = content.split('\n') - const result: { label: string; url: string }[] = [] - for (const line of lines) { - if (line.length > 0) { - const url = `/docs/protocol-reference/transactions/pseudo-transaction-types/${line.toLowerCase()}` - result.push({ label: `${line}`, url }) - result.push({ label: `${line} transaction`, url }) - result.push({ label: `${line} transactions`, url }) + { + path: 'src/content/references/pseudo-transactions.md', + parse: (content: string) => { + const lines = content.split('\n') + const result: { label: string; url: string }[] = [] + for (const line of lines) { + if (line.length > 0) { + const url = `/docs/protocol-reference/transactions/pseudo-transaction-types/${line.toLowerCase()}` + result.push({ label: `${line}`, url }) + result.push({ label: `${line} transaction`, url }) + result.push({ label: `${line} transactions`, url }) + } } - } - return result + return result + }, }, - }, -] + ] /** * Remark plugin to resolve reference-style links from global.md @@ -82,7 +82,7 @@ export function remarkGlobalReferences() { } } - const NON_ROOT_LOCALES = ['es', 'ja'] + const NON_ROOT_LOCALES = ['es', 'ja', 'br'] return function transformer(tree: any, vfile: any) { const refs = loadGlobalReferences() From 4cead98fab181cdba0466dcd538ba132e3770e02 Mon Sep 17 00:00:00 2001 From: Andrei Rosseti Date: Tue, 21 Apr 2026 20:37:18 -0300 Subject: [PATCH 02/20] feat: refactor to pt-br and added more i18n pages --- astro.config.mjs | 62 +- src/components/DocsSidebar.astro | 1 + src/components/Header.jsx | 4 +- src/components/XahauAboutPtBR.astro | 480 ++++++++++++ src/components/XahauConnect.astro | 32 +- src/components/XahauEcosystem.astro | 3 +- src/components/XahauFeaturesPtBR.astro | 729 ++++++++++++++++++ .../ledger-objects-types/deposit-pre-auth.mdx | 45 -- .../ledger-objects-types/directory-node.mdx | 96 --- .../ledger-objects-types/emitted-txn.mdx | 61 -- .../ledger-objects-types/escrow.mdx | 67 -- .../ledger-objects-types/fee-settings.mdx | 64 -- .../ledger-objects-types/hook-definition.mdx | 58 -- .../ledger-objects-types/hook-state.mdx | 42 - .../ledger-data/ledger-objects-types/hook.mdx | 57 -- .../import-vl-sequence.mdx | 36 - .../ledger-objects-types/ledger-hashes.mdx | 72 -- .../ledger-objects-types/negative-unl.mdx | 53 -- .../ledger-objects-types/offer.mdx | 68 -- .../ledger-objects-types/pay-channel.mdx | 99 --- .../ledger-objects-types/ripple-state.mdx | 120 --- .../ledger-objects-types/signers-list.mdx | 98 --- .../ledger-objects-types/ticket.mdx | 44 -- .../ledger-objects-types/unl-report.mdx | 63 -- .../ledger-objects-types/uritoken.mdx | 59 -- .../transaction-types/accountdelete.mdx | 61 -- .../transaction-types/accountset.mdx | 116 --- .../transaction-types/checkcancel.mdx | 30 - .../transaction-types/checkcash.mdx | 38 - .../transaction-types/checkcreate.mdx | 44 -- .../transaction-types/claimreward.mdx | 62 -- .../transaction-types/clawback.mdx | 52 -- .../transaction-types/cronset.mdx | 101 --- .../transaction-types/depositpreauth.mdx | 45 -- .../transaction-types/escrowcancel.mdx | 42 - .../transaction-types/escrowcreate.mdx | 43 -- .../genesismint-emitted-txn.mdx | 57 -- .../transactions/transaction-types/import.mdx | 64 -- .../transactions/transaction-types/invoke.mdx | 40 - .../transaction-types/offercancel.mdx | 44 -- .../transaction-types/offercreate.mdx | 68 -- .../transaction-types/payment.mdx | 113 --- .../transaction-types/paymentchannelclaim.mdx | 60 -- .../paymentchannelcreate.mdx | 40 - .../transactions/transaction-types/remit.mdx | 119 --- .../docs/{br => pt-br}/docs/assets/image.png | Bin .../compliance/responsible-disclosure.mdx | 0 .../docs/compliance/security-audit.mdx | 0 .../{br => pt-br}/docs/data-apis/index.mdx | 0 .../docs/features/amendments.mdx | 0 .../docs/features/balance-adjustments.mdx | 0 .../docs/features/burn-2-mint.mdx | 0 .../developer-tooling/client-libraries.mdx | 0 .../developer-tooling/curated-tooling.mdx | 0 .../developer-tooling/developer-tricks.mdx | 0 .../docs/features/faucet-and-explorer.mdx | 0 .../docs/features/governance-game.mdx | 0 .../http-websocket-apis/admin-api-methods.mdx | 0 .../http-websocket-apis/considerations.mdx | 0 .../public-api-methods.mdx | 0 .../request-formatting-guide.mdx | 0 .../response-formatting-guide.mdx | 0 .../network-features/account-managment.mdx | 0 .../network-features/balance-rewards.mdx | 0 .../docs/features/network-features/check.mdx | 0 .../docs/features/network-features/escrow.mdx | 0 .../docs/features/network-features/hooks.mdx | 0 .../docs/features/network-features/offer.mdx | 0 .../features/network-features/payments.mdx | 0 .../features/network-features/uritoken.mdx | 0 .../docs/features/public-nodes-rpc.mdx | 0 .../features/transaction-signing/index.mdx | 0 .../transaction-signing/transaction-fees.mdx | 0 .../docs/features/versioning-process.mdx | 0 .../docs/hooks/concepts/chaining.mdx | 0 .../docs/hooks/concepts/collect-call.mdx | 0 .../docs/hooks/concepts/compiling-hooks.mdx | 0 .../docs/hooks/concepts/debugging-hooks.mdx | 0 .../hooks/concepts/emitted-transactions.mdx | 0 .../hooks/concepts/execution-metadata.mdx | 0 .../concepts/floating-point-numbers-xfl.mdx | 0 .../docs/hooks/concepts/grants.mdx | 0 .../docs/hooks/concepts/hook-fees.mdx | 0 .../docs/hooks/concepts/hookon-field.mdx | 0 .../concepts/introduction/example-usage.mdx | 0 .../hooks/concepts/introduction/index.mdx | 0 .../hooks/concepts/loops-and-guarding.mdx | 0 .../docs/hooks/concepts/namespaces.mdx | 0 .../docs/hooks/concepts/parameters.mdx | 0 .../reference-counted-hook-definitions.mdx | 0 .../hooks/concepts/serialized-objects.mdx | 0 .../hooks/concepts/sethook-transaction.mdx | 0 .../docs/hooks/concepts/slots-and-keylets.mdx | 0 .../docs/hooks/concepts/state-management.mdx | 0 .../docs/hooks/concepts/terminology.mdx | 0 .../docs/hooks/concepts/weak-and-strong.mdx | 0 .../docs/hooks/functions/control/accept.mdx | 0 .../docs/hooks/functions/control/rollback.mdx | 0 .../developer-defined/cbak-callback.mdx | 0 .../functions/developer-defined/hook.mdx | 0 .../functions/emitted-transaction/emit-1.mdx | 0 .../functions/emitted-transaction/emit.mdx | 0 .../emitted-transaction/etxn_burden.mdx | 0 .../emitted-transaction/etxn_details.mdx | 0 .../emitted-transaction/etxn_fee_base.mdx | 0 .../emitted-transaction/etxn_generation.mdx | 0 .../emitted-transaction/etxn_nonce.mdx | 0 .../emitted-transaction/etxn_reserve.mdx | 0 .../hooks/functions/float/float_compare.mdx | 0 .../hooks/functions/float/float_divide.mdx | 0 .../hooks/functions/float/float_exponent.mdx | 0 .../docs/hooks/functions/float/float_int.mdx | 0 .../hooks/functions/float/float_invert.mdx | 0 .../docs/hooks/functions/float/float_log.mdx | 0 .../hooks/functions/float/float_mantissa.mdx | 0 .../hooks/functions/float/float_mulratio.mdx | 0 .../hooks/functions/float/float_multiply.mdx | 0 .../hooks/functions/float/float_negate.mdx | 0 .../docs/hooks/functions/float/float_one.mdx | 0 .../docs/hooks/functions/float/float_root.mdx | 0 .../docs/hooks/functions/float/float_set.mdx | 0 .../docs/hooks/functions/float/float_sign.mdx | 0 .../docs/hooks/functions/float/float_sto.mdx | 0 .../hooks/functions/float/float_sto_set.mdx | 0 .../docs/hooks/functions/float/float_sum.mdx | 0 .../functions/hook-context/hook_account.mdx | 0 .../functions/hook-context/hook_again.mdx | 0 .../functions/hook-context/hook_hash.mdx | 0 .../functions/hook-context/hook_param.mdx | 0 .../functions/hook-context/hook_param_set.mdx | 0 .../hooks/functions/hook-context/hook_pos.mdx | 0 .../functions/hook-context/hook_skip.mdx | 0 .../docs/hooks/functions/ledger/fee_base.mdx | 0 .../hooks/functions/ledger/ledger_keylet.mdx | 0 .../functions/ledger/ledger_last_hash.mdx | 0 .../functions/ledger/ledger_last_time.mdx | 0 .../hooks/functions/ledger/ledger_nonce.mdx | 0 .../hooks/functions/ledger/ledger_seq.mdx | 0 .../originating-transaction/meta_slot.mdx | 0 .../originating-transaction/otxn_burden.mdx | 0 .../originating-transaction/otxn_field.mdx | 0 .../otxn_generation.mdx | 0 .../originating-transaction/otxn_id.mdx | 0 .../originating-transaction/otxn_json.mdx | 0 .../originating-transaction/otxn_param.mdx | 0 .../originating-transaction/otxn_slot.mdx | 0 .../originating-transaction/otxn_type.mdx | 0 .../overview/hook-api-conventions.mdx | 0 .../hooks/functions/overview/return-codes.mdx | 0 .../functions/serialization/sto_emplace.mdx | 0 .../functions/serialization/sto_erase.mdx | 0 .../functions/serialization/sto_from_json.mdx | 0 .../functions/serialization/sto_subarray.mdx | 0 .../functions/serialization/sto_subfield.mdx | 0 .../functions/serialization/sto_to_json.mdx | 0 .../functions/serialization/sto_validate.mdx | 0 .../docs/hooks/functions/slot/slot.mdx | 0 .../docs/hooks/functions/slot/slot_clear.mdx | 0 .../docs/hooks/functions/slot/slot_count.mdx | 0 .../docs/hooks/functions/slot/slot_float.mdx | 0 .../docs/hooks/functions/slot/slot_set.mdx | 0 .../docs/hooks/functions/slot/slot_size.mdx | 0 .../hooks/functions/slot/slot_subarray.mdx | 0 .../hooks/functions/slot/slot_subfield.mdx | 0 .../docs/hooks/functions/slot/slot_type.mdx | 0 .../docs/hooks/functions/slot/xpop_slot.mdx | 0 .../docs/hooks/functions/state/state.mdx | 0 .../hooks/functions/state/state_foreign.mdx | 0 .../functions/state/state_foreign_set.mdx | 0 .../docs/hooks/functions/state/state_set.mdx | 0 .../hooks/functions/trace-debug/trace.mdx | 0 .../functions/trace-debug/trace_float.mdx | 0 .../hooks/functions/trace-debug/trace_num.mdx | 0 .../hooks/functions/utilities/util_accid.mdx | 0 .../hooks/functions/utilities/util_keylet.mdx | 0 .../hooks/functions/utilities/util_raddr.mdx | 0 .../functions/utilities/util_sha512h.mdx | 0 .../hooks/functions/utilities/util_verify.mdx | 0 .../functions/websocket-apis/account_info.mdx | 0 .../websocket-apis/account_namespace.mdx | 0 .../docs/{br => pt-br}/docs/hooks/index.mdx | 0 src/content/docs/{br => pt-br}/docs/index.mdx | 0 .../infrastructure/advanced-configuration.mdx | 0 .../infrastructure/build-xahaud/index.mdx | 0 .../infrastructure/build-xahaud/linux.mdx | 0 .../infrastructure/build-xahaud/macos.mdx | 0 .../infrastructure/enabling-validation.mdx | 0 .../docs/infrastructure/identity.mdx | 0 .../docs/infrastructure/installing-xahaud.mdx | 0 .../docs/infrastructure/interacting.mdx | 0 .../infrastructure/system-requirements.mdx | 0 .../docs/infrastructure/updating-xahaud.mdx | 0 .../docs/protocol-reference/binary-format.mdx | 0 .../data-types/base-58-encodings.mdx | 0 .../data-types/currency-formats.mdx | 0 .../protocol-reference/data-types/index.mdx | 0 .../protocol-reference/ledger-data/index.mdx | 0 .../ledger-data/ledger-header.mdx | 0 .../ledger-data/ledger-object-ids.mdx | 0 .../ledger-objects-types/accountroot.mdx | 0 .../ledger-objects-types/amendments.mdx | 0 .../ledger-objects-types/check.mdx | 0 .../ledger-data/ledger-objects-types/cron.mdx | 0 .../ledger-objects-types/deposit-pre-auth.mdx | 45 ++ .../ledger-objects-types/directory-node.mdx | 96 +++ .../ledger-objects-types/emitted-txn.mdx | 61 ++ .../ledger-objects-types/escrow.mdx | 67 ++ .../ledger-objects-types/fee-settings.mdx | 64 ++ .../ledger-objects-types/hook-definition.mdx | 58 ++ .../ledger-objects-types/hook-state.mdx | 42 + .../ledger-data/ledger-objects-types/hook.mdx | 57 ++ .../import-vl-sequence.mdx | 36 + .../ledger-objects-types/index.mdx | 0 .../ledger-objects-types/ledger-hashes.mdx | 72 ++ .../ledger-objects-types/negative-unl.mdx | 53 ++ .../ledger-objects-types/offer.mdx | 68 ++ .../ledger-objects-types/pay-channel.mdx | 99 +++ .../ledger-objects-types/ripple-state.mdx | 120 +++ .../ledger-objects-types/signers-list.mdx | 98 +++ .../ledger-objects-types/ticket.mdx | 44 ++ .../ledger-objects-types/unl-report.mdx | 63 ++ .../ledger-objects-types/uritoken.mdx | 59 ++ .../protocol-reference/transactions/index.mdx | 0 .../pseudo-transaction-types/cron.mdx | 0 .../pseudo-transaction-types/emitfailure.mdx | 0 .../enableamendment.mdx | 0 .../pseudo-transaction-types/index.mdx | 0 .../pseudo-transaction-types/setfee.mdx | 0 .../pseudo-transaction-types/unlmodify.mdx | 0 .../pseudo-transaction-types/unlreport.mdx | 0 .../transaction-common-fields.mdx | 0 .../transactions/transaction-metadata.mdx | 0 .../transaction-results/index.mdx | 0 .../transaction-results/tec-codes.mdx | 0 .../transaction-results/tef-codes.mdx | 0 .../transaction-results/tel-codes.mdx | 0 .../transaction-results/tem-codes.mdx | 0 .../transaction-results/ter-codes.mdx | 0 .../transaction-results/tes-codes.mdx | 0 .../transaction-types/accountdelete.mdx | 60 ++ .../transaction-types/accountset.mdx | 116 +++ .../transaction-types/checkcancel.mdx | 30 + .../transaction-types/checkcash.mdx | 38 + .../transaction-types/checkcreate.mdx | 44 ++ .../transaction-types/claimreward.mdx | 63 ++ .../transaction-types/clawback.mdx | 52 ++ .../transaction-types/cronset.mdx | 101 +++ .../transaction-types/depositpreauth.mdx | 45 ++ .../transaction-types/escrowcancel.mdx | 42 + .../transaction-types/escrowcreate.mdx | 43 ++ .../transaction-types/escrowfinish.mdx | 10 +- .../genesismint-emitted-txn.mdx | 57 ++ .../transactions/transaction-types/import.mdx | 64 ++ .../transactions/transaction-types/index.mdx | 0 .../transactions/transaction-types/invoke.mdx | 40 + .../transaction-types/offercancel.mdx | 44 ++ .../transaction-types/offercreate.mdx | 68 ++ .../transaction-types/payment.mdx | 113 +++ .../transaction-types/paymentchannelclaim.mdx | 60 ++ .../paymentchannelcreate.mdx | 40 + .../transaction-types/paymentchannelfund.mdx | 40 +- .../transactions/transaction-types/remit.mdx | 119 +++ .../transaction-types/sethook.mdx | 0 .../transaction-types/setregularkey.mdx | 0 .../transaction-types/setremarks.mdx | 0 .../transaction-types/signerlistset.mdx | 0 .../transaction-types/ticketcreate.mdx | 0 .../transaction-types/trustset.mdx | 0 .../transaction-types/uritokenburn.mdx | 0 .../transaction-types/uritokenbuy.mdx | 0 .../uritokencancelselloffer.mdx | 0 .../uritokencreateselloffer.mdx | 0 .../transaction-types/uritokenmint.mdx | 0 .../docs/resources/media-kit.mdx | 0 .../docs/resources/whitepaper.mdx | 0 .../{br => pt-br}/docs/support/help-us.mdx | 0 .../{br => pt-br}/docs/what-is-different.mdx | 22 +- src/i18n/fraudReportTranslations.ts | 4 +- src/i18n/indexTranslations.ts | 2 +- src/pages/br/about.mdx | 57 -- src/pages/br/connect.mdx | 210 ----- src/pages/br/contest.mdx | 251 ------ src/pages/br/ecosystem.mdx | 172 ----- src/pages/br/features.mdx | 96 --- src/pages/br/roadmap.mdx | 70 -- src/pages/pt-br/about.astro | 16 + src/pages/pt-br/connect.astro | 17 + src/pages/pt-br/contest.astro | 16 + src/pages/pt-br/ecosystem.astro | 16 + src/pages/pt-br/features.astro | 16 + src/pages/{br => pt-br}/fraud-report.astro | 0 src/pages/{br => pt-br}/index.mdx | 0 src/pages/{br => pt-br}/privacy-policy.mdx | 0 src/pages/pt-br/roadmap.astro | 16 + src/plugins/remarkGlobalReferences.ts | 2 +- src/utils/localizedHref.ts | 2 +- 296 files changed, 3854 insertions(+), 3374 deletions(-) create mode 100644 src/components/XahauAboutPtBR.astro create mode 100644 src/components/XahauFeaturesPtBR.astro delete mode 100644 src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/deposit-pre-auth.mdx delete mode 100644 src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/directory-node.mdx delete mode 100644 src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/emitted-txn.mdx delete mode 100644 src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/escrow.mdx delete mode 100644 src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/fee-settings.mdx delete mode 100644 src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/hook-definition.mdx delete mode 100644 src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/hook-state.mdx delete mode 100644 src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/hook.mdx delete mode 100644 src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/import-vl-sequence.mdx delete mode 100644 src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/ledger-hashes.mdx delete mode 100644 src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/negative-unl.mdx delete mode 100644 src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/offer.mdx delete mode 100644 src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/pay-channel.mdx delete mode 100644 src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/ripple-state.mdx delete mode 100644 src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/signers-list.mdx delete mode 100644 src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/ticket.mdx delete mode 100644 src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/unl-report.mdx delete mode 100644 src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/uritoken.mdx delete mode 100644 src/content/docs/br/docs/protocol-reference/transactions/transaction-types/accountdelete.mdx delete mode 100644 src/content/docs/br/docs/protocol-reference/transactions/transaction-types/accountset.mdx delete mode 100644 src/content/docs/br/docs/protocol-reference/transactions/transaction-types/checkcancel.mdx delete mode 100644 src/content/docs/br/docs/protocol-reference/transactions/transaction-types/checkcash.mdx delete mode 100644 src/content/docs/br/docs/protocol-reference/transactions/transaction-types/checkcreate.mdx delete mode 100644 src/content/docs/br/docs/protocol-reference/transactions/transaction-types/claimreward.mdx delete mode 100644 src/content/docs/br/docs/protocol-reference/transactions/transaction-types/clawback.mdx delete mode 100644 src/content/docs/br/docs/protocol-reference/transactions/transaction-types/cronset.mdx delete mode 100644 src/content/docs/br/docs/protocol-reference/transactions/transaction-types/depositpreauth.mdx delete mode 100644 src/content/docs/br/docs/protocol-reference/transactions/transaction-types/escrowcancel.mdx delete mode 100644 src/content/docs/br/docs/protocol-reference/transactions/transaction-types/escrowcreate.mdx delete mode 100644 src/content/docs/br/docs/protocol-reference/transactions/transaction-types/genesismint-emitted-txn.mdx delete mode 100644 src/content/docs/br/docs/protocol-reference/transactions/transaction-types/import.mdx delete mode 100644 src/content/docs/br/docs/protocol-reference/transactions/transaction-types/invoke.mdx delete mode 100644 src/content/docs/br/docs/protocol-reference/transactions/transaction-types/offercancel.mdx delete mode 100644 src/content/docs/br/docs/protocol-reference/transactions/transaction-types/offercreate.mdx delete mode 100644 src/content/docs/br/docs/protocol-reference/transactions/transaction-types/payment.mdx delete mode 100644 src/content/docs/br/docs/protocol-reference/transactions/transaction-types/paymentchannelclaim.mdx delete mode 100644 src/content/docs/br/docs/protocol-reference/transactions/transaction-types/paymentchannelcreate.mdx delete mode 100644 src/content/docs/br/docs/protocol-reference/transactions/transaction-types/remit.mdx rename src/content/docs/{br => pt-br}/docs/assets/image.png (100%) rename src/content/docs/{br => pt-br}/docs/compliance/responsible-disclosure.mdx (100%) rename src/content/docs/{br => pt-br}/docs/compliance/security-audit.mdx (100%) rename src/content/docs/{br => pt-br}/docs/data-apis/index.mdx (100%) rename src/content/docs/{br => pt-br}/docs/features/amendments.mdx (100%) rename src/content/docs/{br => pt-br}/docs/features/balance-adjustments.mdx (100%) rename src/content/docs/{br => pt-br}/docs/features/burn-2-mint.mdx (100%) rename src/content/docs/{br => pt-br}/docs/features/developer-tooling/client-libraries.mdx (100%) rename src/content/docs/{br => pt-br}/docs/features/developer-tooling/curated-tooling.mdx (100%) rename src/content/docs/{br => pt-br}/docs/features/developer-tooling/developer-tricks.mdx (100%) rename src/content/docs/{br => pt-br}/docs/features/faucet-and-explorer.mdx (100%) rename src/content/docs/{br => pt-br}/docs/features/governance-game.mdx (100%) rename src/content/docs/{br => pt-br}/docs/features/http-websocket-apis/admin-api-methods.mdx (100%) rename src/content/docs/{br => pt-br}/docs/features/http-websocket-apis/considerations.mdx (100%) rename src/content/docs/{br => pt-br}/docs/features/http-websocket-apis/public-api-methods.mdx (100%) rename src/content/docs/{br => pt-br}/docs/features/http-websocket-apis/request-formatting-guide.mdx (100%) rename src/content/docs/{br => pt-br}/docs/features/http-websocket-apis/response-formatting-guide.mdx (100%) rename src/content/docs/{br => pt-br}/docs/features/network-features/account-managment.mdx (100%) rename src/content/docs/{br => pt-br}/docs/features/network-features/balance-rewards.mdx (100%) rename src/content/docs/{br => pt-br}/docs/features/network-features/check.mdx (100%) rename src/content/docs/{br => pt-br}/docs/features/network-features/escrow.mdx (100%) rename src/content/docs/{br => pt-br}/docs/features/network-features/hooks.mdx (100%) rename src/content/docs/{br => pt-br}/docs/features/network-features/offer.mdx (100%) rename src/content/docs/{br => pt-br}/docs/features/network-features/payments.mdx (100%) rename src/content/docs/{br => pt-br}/docs/features/network-features/uritoken.mdx (100%) rename src/content/docs/{br => pt-br}/docs/features/public-nodes-rpc.mdx (100%) rename src/content/docs/{br => pt-br}/docs/features/transaction-signing/index.mdx (100%) rename src/content/docs/{br => pt-br}/docs/features/transaction-signing/transaction-fees.mdx (100%) rename src/content/docs/{br => pt-br}/docs/features/versioning-process.mdx (100%) rename src/content/docs/{br => pt-br}/docs/hooks/concepts/chaining.mdx (100%) rename src/content/docs/{br => pt-br}/docs/hooks/concepts/collect-call.mdx (100%) rename src/content/docs/{br => pt-br}/docs/hooks/concepts/compiling-hooks.mdx (100%) rename src/content/docs/{br => pt-br}/docs/hooks/concepts/debugging-hooks.mdx (100%) rename src/content/docs/{br => pt-br}/docs/hooks/concepts/emitted-transactions.mdx (100%) rename src/content/docs/{br => pt-br}/docs/hooks/concepts/execution-metadata.mdx (100%) rename src/content/docs/{br => pt-br}/docs/hooks/concepts/floating-point-numbers-xfl.mdx (100%) rename src/content/docs/{br => pt-br}/docs/hooks/concepts/grants.mdx (100%) rename src/content/docs/{br => pt-br}/docs/hooks/concepts/hook-fees.mdx (100%) rename src/content/docs/{br => pt-br}/docs/hooks/concepts/hookon-field.mdx (100%) rename src/content/docs/{br => pt-br}/docs/hooks/concepts/introduction/example-usage.mdx (100%) rename src/content/docs/{br => pt-br}/docs/hooks/concepts/introduction/index.mdx (100%) rename src/content/docs/{br => pt-br}/docs/hooks/concepts/loops-and-guarding.mdx (100%) rename src/content/docs/{br => pt-br}/docs/hooks/concepts/namespaces.mdx (100%) rename src/content/docs/{br => pt-br}/docs/hooks/concepts/parameters.mdx (100%) rename src/content/docs/{br => pt-br}/docs/hooks/concepts/reference-counted-hook-definitions.mdx (100%) rename src/content/docs/{br => pt-br}/docs/hooks/concepts/serialized-objects.mdx (100%) rename src/content/docs/{br => pt-br}/docs/hooks/concepts/sethook-transaction.mdx (100%) rename src/content/docs/{br => pt-br}/docs/hooks/concepts/slots-and-keylets.mdx (100%) rename src/content/docs/{br => pt-br}/docs/hooks/concepts/state-management.mdx (100%) rename src/content/docs/{br => pt-br}/docs/hooks/concepts/terminology.mdx (100%) rename src/content/docs/{br => pt-br}/docs/hooks/concepts/weak-and-strong.mdx (100%) rename src/content/docs/{br => pt-br}/docs/hooks/functions/control/accept.mdx (100%) rename src/content/docs/{br => pt-br}/docs/hooks/functions/control/rollback.mdx (100%) rename src/content/docs/{br => pt-br}/docs/hooks/functions/developer-defined/cbak-callback.mdx (100%) rename src/content/docs/{br => pt-br}/docs/hooks/functions/developer-defined/hook.mdx (100%) rename src/content/docs/{br => pt-br}/docs/hooks/functions/emitted-transaction/emit-1.mdx (100%) rename src/content/docs/{br => pt-br}/docs/hooks/functions/emitted-transaction/emit.mdx (100%) rename src/content/docs/{br => pt-br}/docs/hooks/functions/emitted-transaction/etxn_burden.mdx (100%) rename src/content/docs/{br => pt-br}/docs/hooks/functions/emitted-transaction/etxn_details.mdx (100%) rename src/content/docs/{br => pt-br}/docs/hooks/functions/emitted-transaction/etxn_fee_base.mdx (100%) rename src/content/docs/{br => pt-br}/docs/hooks/functions/emitted-transaction/etxn_generation.mdx (100%) rename src/content/docs/{br => pt-br}/docs/hooks/functions/emitted-transaction/etxn_nonce.mdx (100%) rename src/content/docs/{br => pt-br}/docs/hooks/functions/emitted-transaction/etxn_reserve.mdx (100%) rename src/content/docs/{br => pt-br}/docs/hooks/functions/float/float_compare.mdx (100%) rename src/content/docs/{br => pt-br}/docs/hooks/functions/float/float_divide.mdx (100%) rename src/content/docs/{br => pt-br}/docs/hooks/functions/float/float_exponent.mdx (100%) rename src/content/docs/{br => pt-br}/docs/hooks/functions/float/float_int.mdx (100%) rename src/content/docs/{br => pt-br}/docs/hooks/functions/float/float_invert.mdx (100%) rename src/content/docs/{br => pt-br}/docs/hooks/functions/float/float_log.mdx (100%) rename src/content/docs/{br => pt-br}/docs/hooks/functions/float/float_mantissa.mdx (100%) rename src/content/docs/{br => pt-br}/docs/hooks/functions/float/float_mulratio.mdx (100%) rename src/content/docs/{br => pt-br}/docs/hooks/functions/float/float_multiply.mdx (100%) rename src/content/docs/{br => pt-br}/docs/hooks/functions/float/float_negate.mdx (100%) rename src/content/docs/{br => pt-br}/docs/hooks/functions/float/float_one.mdx (100%) rename src/content/docs/{br => pt-br}/docs/hooks/functions/float/float_root.mdx (100%) rename src/content/docs/{br => pt-br}/docs/hooks/functions/float/float_set.mdx (100%) rename src/content/docs/{br => pt-br}/docs/hooks/functions/float/float_sign.mdx (100%) rename src/content/docs/{br => pt-br}/docs/hooks/functions/float/float_sto.mdx (100%) rename src/content/docs/{br => pt-br}/docs/hooks/functions/float/float_sto_set.mdx (100%) rename src/content/docs/{br => pt-br}/docs/hooks/functions/float/float_sum.mdx (100%) rename src/content/docs/{br => pt-br}/docs/hooks/functions/hook-context/hook_account.mdx (100%) rename src/content/docs/{br => pt-br}/docs/hooks/functions/hook-context/hook_again.mdx (100%) rename src/content/docs/{br => pt-br}/docs/hooks/functions/hook-context/hook_hash.mdx (100%) rename src/content/docs/{br => pt-br}/docs/hooks/functions/hook-context/hook_param.mdx (100%) rename src/content/docs/{br => pt-br}/docs/hooks/functions/hook-context/hook_param_set.mdx (100%) rename src/content/docs/{br => pt-br}/docs/hooks/functions/hook-context/hook_pos.mdx (100%) rename src/content/docs/{br => pt-br}/docs/hooks/functions/hook-context/hook_skip.mdx (100%) rename src/content/docs/{br => pt-br}/docs/hooks/functions/ledger/fee_base.mdx (100%) rename src/content/docs/{br => pt-br}/docs/hooks/functions/ledger/ledger_keylet.mdx (100%) rename src/content/docs/{br => pt-br}/docs/hooks/functions/ledger/ledger_last_hash.mdx (100%) rename src/content/docs/{br => pt-br}/docs/hooks/functions/ledger/ledger_last_time.mdx (100%) rename src/content/docs/{br => pt-br}/docs/hooks/functions/ledger/ledger_nonce.mdx (100%) rename src/content/docs/{br => pt-br}/docs/hooks/functions/ledger/ledger_seq.mdx (100%) rename src/content/docs/{br => pt-br}/docs/hooks/functions/originating-transaction/meta_slot.mdx (100%) rename src/content/docs/{br => pt-br}/docs/hooks/functions/originating-transaction/otxn_burden.mdx (100%) rename src/content/docs/{br => pt-br}/docs/hooks/functions/originating-transaction/otxn_field.mdx (100%) rename src/content/docs/{br => pt-br}/docs/hooks/functions/originating-transaction/otxn_generation.mdx (100%) rename src/content/docs/{br => pt-br}/docs/hooks/functions/originating-transaction/otxn_id.mdx (100%) rename src/content/docs/{br => pt-br}/docs/hooks/functions/originating-transaction/otxn_json.mdx (100%) rename src/content/docs/{br => pt-br}/docs/hooks/functions/originating-transaction/otxn_param.mdx (100%) rename src/content/docs/{br => pt-br}/docs/hooks/functions/originating-transaction/otxn_slot.mdx (100%) rename src/content/docs/{br => pt-br}/docs/hooks/functions/originating-transaction/otxn_type.mdx (100%) rename src/content/docs/{br => pt-br}/docs/hooks/functions/overview/hook-api-conventions.mdx (100%) rename src/content/docs/{br => pt-br}/docs/hooks/functions/overview/return-codes.mdx (100%) rename src/content/docs/{br => pt-br}/docs/hooks/functions/serialization/sto_emplace.mdx (100%) rename src/content/docs/{br => pt-br}/docs/hooks/functions/serialization/sto_erase.mdx (100%) rename src/content/docs/{br => pt-br}/docs/hooks/functions/serialization/sto_from_json.mdx (100%) rename src/content/docs/{br => pt-br}/docs/hooks/functions/serialization/sto_subarray.mdx (100%) rename src/content/docs/{br => pt-br}/docs/hooks/functions/serialization/sto_subfield.mdx (100%) rename src/content/docs/{br => pt-br}/docs/hooks/functions/serialization/sto_to_json.mdx (100%) rename src/content/docs/{br => pt-br}/docs/hooks/functions/serialization/sto_validate.mdx (100%) rename src/content/docs/{br => pt-br}/docs/hooks/functions/slot/slot.mdx (100%) rename src/content/docs/{br => pt-br}/docs/hooks/functions/slot/slot_clear.mdx (100%) rename src/content/docs/{br => pt-br}/docs/hooks/functions/slot/slot_count.mdx (100%) rename src/content/docs/{br => pt-br}/docs/hooks/functions/slot/slot_float.mdx (100%) rename src/content/docs/{br => pt-br}/docs/hooks/functions/slot/slot_set.mdx (100%) rename src/content/docs/{br => pt-br}/docs/hooks/functions/slot/slot_size.mdx (100%) rename src/content/docs/{br => pt-br}/docs/hooks/functions/slot/slot_subarray.mdx (100%) rename src/content/docs/{br => pt-br}/docs/hooks/functions/slot/slot_subfield.mdx (100%) rename src/content/docs/{br => pt-br}/docs/hooks/functions/slot/slot_type.mdx (100%) rename src/content/docs/{br => pt-br}/docs/hooks/functions/slot/xpop_slot.mdx (100%) rename src/content/docs/{br => pt-br}/docs/hooks/functions/state/state.mdx (100%) rename src/content/docs/{br => pt-br}/docs/hooks/functions/state/state_foreign.mdx (100%) rename src/content/docs/{br => pt-br}/docs/hooks/functions/state/state_foreign_set.mdx (100%) rename src/content/docs/{br => pt-br}/docs/hooks/functions/state/state_set.mdx (100%) rename src/content/docs/{br => pt-br}/docs/hooks/functions/trace-debug/trace.mdx (100%) rename src/content/docs/{br => pt-br}/docs/hooks/functions/trace-debug/trace_float.mdx (100%) rename src/content/docs/{br => pt-br}/docs/hooks/functions/trace-debug/trace_num.mdx (100%) rename src/content/docs/{br => pt-br}/docs/hooks/functions/utilities/util_accid.mdx (100%) rename src/content/docs/{br => pt-br}/docs/hooks/functions/utilities/util_keylet.mdx (100%) rename src/content/docs/{br => pt-br}/docs/hooks/functions/utilities/util_raddr.mdx (100%) rename src/content/docs/{br => pt-br}/docs/hooks/functions/utilities/util_sha512h.mdx (100%) rename src/content/docs/{br => pt-br}/docs/hooks/functions/utilities/util_verify.mdx (100%) rename src/content/docs/{br => pt-br}/docs/hooks/functions/websocket-apis/account_info.mdx (100%) rename src/content/docs/{br => pt-br}/docs/hooks/functions/websocket-apis/account_namespace.mdx (100%) rename src/content/docs/{br => pt-br}/docs/hooks/index.mdx (100%) rename src/content/docs/{br => pt-br}/docs/index.mdx (100%) rename src/content/docs/{br => pt-br}/docs/infrastructure/advanced-configuration.mdx (100%) rename src/content/docs/{br => pt-br}/docs/infrastructure/build-xahaud/index.mdx (100%) rename src/content/docs/{br => pt-br}/docs/infrastructure/build-xahaud/linux.mdx (100%) rename src/content/docs/{br => pt-br}/docs/infrastructure/build-xahaud/macos.mdx (100%) rename src/content/docs/{br => pt-br}/docs/infrastructure/enabling-validation.mdx (100%) rename src/content/docs/{br => pt-br}/docs/infrastructure/identity.mdx (100%) rename src/content/docs/{br => pt-br}/docs/infrastructure/installing-xahaud.mdx (100%) rename src/content/docs/{br => pt-br}/docs/infrastructure/interacting.mdx (100%) rename src/content/docs/{br => pt-br}/docs/infrastructure/system-requirements.mdx (100%) rename src/content/docs/{br => pt-br}/docs/infrastructure/updating-xahaud.mdx (100%) rename src/content/docs/{br => pt-br}/docs/protocol-reference/binary-format.mdx (100%) rename src/content/docs/{br => pt-br}/docs/protocol-reference/data-types/base-58-encodings.mdx (100%) rename src/content/docs/{br => pt-br}/docs/protocol-reference/data-types/currency-formats.mdx (100%) rename src/content/docs/{br => pt-br}/docs/protocol-reference/data-types/index.mdx (100%) rename src/content/docs/{br => pt-br}/docs/protocol-reference/ledger-data/index.mdx (100%) rename src/content/docs/{br => pt-br}/docs/protocol-reference/ledger-data/ledger-header.mdx (100%) rename src/content/docs/{br => pt-br}/docs/protocol-reference/ledger-data/ledger-object-ids.mdx (100%) rename src/content/docs/{br => pt-br}/docs/protocol-reference/ledger-data/ledger-objects-types/accountroot.mdx (100%) rename src/content/docs/{br => pt-br}/docs/protocol-reference/ledger-data/ledger-objects-types/amendments.mdx (100%) rename src/content/docs/{br => pt-br}/docs/protocol-reference/ledger-data/ledger-objects-types/check.mdx (100%) rename src/content/docs/{br => pt-br}/docs/protocol-reference/ledger-data/ledger-objects-types/cron.mdx (100%) create mode 100644 src/content/docs/pt-br/docs/protocol-reference/ledger-data/ledger-objects-types/deposit-pre-auth.mdx create mode 100644 src/content/docs/pt-br/docs/protocol-reference/ledger-data/ledger-objects-types/directory-node.mdx create mode 100644 src/content/docs/pt-br/docs/protocol-reference/ledger-data/ledger-objects-types/emitted-txn.mdx create mode 100644 src/content/docs/pt-br/docs/protocol-reference/ledger-data/ledger-objects-types/escrow.mdx create mode 100644 src/content/docs/pt-br/docs/protocol-reference/ledger-data/ledger-objects-types/fee-settings.mdx create mode 100644 src/content/docs/pt-br/docs/protocol-reference/ledger-data/ledger-objects-types/hook-definition.mdx create mode 100644 src/content/docs/pt-br/docs/protocol-reference/ledger-data/ledger-objects-types/hook-state.mdx create mode 100644 src/content/docs/pt-br/docs/protocol-reference/ledger-data/ledger-objects-types/hook.mdx create mode 100644 src/content/docs/pt-br/docs/protocol-reference/ledger-data/ledger-objects-types/import-vl-sequence.mdx rename src/content/docs/{br => pt-br}/docs/protocol-reference/ledger-data/ledger-objects-types/index.mdx (100%) create mode 100644 src/content/docs/pt-br/docs/protocol-reference/ledger-data/ledger-objects-types/ledger-hashes.mdx create mode 100644 src/content/docs/pt-br/docs/protocol-reference/ledger-data/ledger-objects-types/negative-unl.mdx create mode 100644 src/content/docs/pt-br/docs/protocol-reference/ledger-data/ledger-objects-types/offer.mdx create mode 100644 src/content/docs/pt-br/docs/protocol-reference/ledger-data/ledger-objects-types/pay-channel.mdx create mode 100644 src/content/docs/pt-br/docs/protocol-reference/ledger-data/ledger-objects-types/ripple-state.mdx create mode 100644 src/content/docs/pt-br/docs/protocol-reference/ledger-data/ledger-objects-types/signers-list.mdx create mode 100644 src/content/docs/pt-br/docs/protocol-reference/ledger-data/ledger-objects-types/ticket.mdx create mode 100644 src/content/docs/pt-br/docs/protocol-reference/ledger-data/ledger-objects-types/unl-report.mdx create mode 100644 src/content/docs/pt-br/docs/protocol-reference/ledger-data/ledger-objects-types/uritoken.mdx rename src/content/docs/{br => pt-br}/docs/protocol-reference/transactions/index.mdx (100%) rename src/content/docs/{br => pt-br}/docs/protocol-reference/transactions/pseudo-transaction-types/cron.mdx (100%) rename src/content/docs/{br => pt-br}/docs/protocol-reference/transactions/pseudo-transaction-types/emitfailure.mdx (100%) rename src/content/docs/{br => pt-br}/docs/protocol-reference/transactions/pseudo-transaction-types/enableamendment.mdx (100%) rename src/content/docs/{br => pt-br}/docs/protocol-reference/transactions/pseudo-transaction-types/index.mdx (100%) rename src/content/docs/{br => pt-br}/docs/protocol-reference/transactions/pseudo-transaction-types/setfee.mdx (100%) rename src/content/docs/{br => pt-br}/docs/protocol-reference/transactions/pseudo-transaction-types/unlmodify.mdx (100%) rename src/content/docs/{br => pt-br}/docs/protocol-reference/transactions/pseudo-transaction-types/unlreport.mdx (100%) rename src/content/docs/{br => pt-br}/docs/protocol-reference/transactions/transaction-common-fields.mdx (100%) rename src/content/docs/{br => pt-br}/docs/protocol-reference/transactions/transaction-metadata.mdx (100%) rename src/content/docs/{br => pt-br}/docs/protocol-reference/transactions/transaction-results/index.mdx (100%) rename src/content/docs/{br => pt-br}/docs/protocol-reference/transactions/transaction-results/tec-codes.mdx (100%) rename src/content/docs/{br => pt-br}/docs/protocol-reference/transactions/transaction-results/tef-codes.mdx (100%) rename src/content/docs/{br => pt-br}/docs/protocol-reference/transactions/transaction-results/tel-codes.mdx (100%) rename src/content/docs/{br => pt-br}/docs/protocol-reference/transactions/transaction-results/tem-codes.mdx (100%) rename src/content/docs/{br => pt-br}/docs/protocol-reference/transactions/transaction-results/ter-codes.mdx (100%) rename src/content/docs/{br => pt-br}/docs/protocol-reference/transactions/transaction-results/tes-codes.mdx (100%) create mode 100644 src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-types/accountdelete.mdx create mode 100644 src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-types/accountset.mdx create mode 100644 src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-types/checkcancel.mdx create mode 100644 src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-types/checkcash.mdx create mode 100644 src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-types/checkcreate.mdx create mode 100644 src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-types/claimreward.mdx create mode 100644 src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-types/clawback.mdx create mode 100644 src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-types/cronset.mdx create mode 100644 src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-types/depositpreauth.mdx create mode 100644 src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-types/escrowcancel.mdx create mode 100644 src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-types/escrowcreate.mdx rename src/content/docs/{br => pt-br}/docs/protocol-reference/transactions/transaction-types/escrowfinish.mdx (94%) create mode 100644 src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-types/genesismint-emitted-txn.mdx create mode 100644 src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-types/import.mdx rename src/content/docs/{br => pt-br}/docs/protocol-reference/transactions/transaction-types/index.mdx (100%) create mode 100644 src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-types/invoke.mdx create mode 100644 src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-types/offercancel.mdx create mode 100644 src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-types/offercreate.mdx create mode 100644 src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-types/payment.mdx create mode 100644 src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-types/paymentchannelclaim.mdx create mode 100644 src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-types/paymentchannelcreate.mdx rename src/content/docs/{br => pt-br}/docs/protocol-reference/transactions/transaction-types/paymentchannelfund.mdx (55%) create mode 100644 src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-types/remit.mdx rename src/content/docs/{br => pt-br}/docs/protocol-reference/transactions/transaction-types/sethook.mdx (100%) rename src/content/docs/{br => pt-br}/docs/protocol-reference/transactions/transaction-types/setregularkey.mdx (100%) rename src/content/docs/{br => pt-br}/docs/protocol-reference/transactions/transaction-types/setremarks.mdx (100%) rename src/content/docs/{br => pt-br}/docs/protocol-reference/transactions/transaction-types/signerlistset.mdx (100%) rename src/content/docs/{br => pt-br}/docs/protocol-reference/transactions/transaction-types/ticketcreate.mdx (100%) rename src/content/docs/{br => pt-br}/docs/protocol-reference/transactions/transaction-types/trustset.mdx (100%) rename src/content/docs/{br => pt-br}/docs/protocol-reference/transactions/transaction-types/uritokenburn.mdx (100%) rename src/content/docs/{br => pt-br}/docs/protocol-reference/transactions/transaction-types/uritokenbuy.mdx (100%) rename src/content/docs/{br => pt-br}/docs/protocol-reference/transactions/transaction-types/uritokencancelselloffer.mdx (100%) rename src/content/docs/{br => pt-br}/docs/protocol-reference/transactions/transaction-types/uritokencreateselloffer.mdx (100%) rename src/content/docs/{br => pt-br}/docs/protocol-reference/transactions/transaction-types/uritokenmint.mdx (100%) rename src/content/docs/{br => pt-br}/docs/resources/media-kit.mdx (100%) rename src/content/docs/{br => pt-br}/docs/resources/whitepaper.mdx (100%) rename src/content/docs/{br => pt-br}/docs/support/help-us.mdx (100%) rename src/content/docs/{br => pt-br}/docs/what-is-different.mdx (80%) delete mode 100644 src/pages/br/about.mdx delete mode 100644 src/pages/br/connect.mdx delete mode 100644 src/pages/br/contest.mdx delete mode 100644 src/pages/br/ecosystem.mdx delete mode 100644 src/pages/br/features.mdx delete mode 100644 src/pages/br/roadmap.mdx create mode 100644 src/pages/pt-br/about.astro create mode 100644 src/pages/pt-br/connect.astro create mode 100644 src/pages/pt-br/contest.astro create mode 100644 src/pages/pt-br/ecosystem.astro create mode 100644 src/pages/pt-br/features.astro rename src/pages/{br => pt-br}/fraud-report.astro (100%) rename src/pages/{br => pt-br}/index.mdx (100%) rename src/pages/{br => pt-br}/privacy-policy.mdx (100%) create mode 100644 src/pages/pt-br/roadmap.astro diff --git a/astro.config.mjs b/astro.config.mjs index bde75cc..faabde0 100644 --- a/astro.config.mjs +++ b/astro.config.mjs @@ -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' }, }, ], diff --git a/src/components/DocsSidebar.astro b/src/components/DocsSidebar.astro index f7e7224..4b612bd 100644 --- a/src/components/DocsSidebar.astro +++ b/src/components/DocsSidebar.astro @@ -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) --- diff --git a/src/components/Header.jsx b/src/components/Header.jsx index 44f7257..206b2fd 100644 --- a/src/components/Header.jsx +++ b/src/components/Header.jsx @@ -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', diff --git a/src/components/XahauAboutPtBR.astro b/src/components/XahauAboutPtBR.astro new file mode 100644 index 0000000..ce19b78 --- /dev/null +++ b/src/components/XahauAboutPtBR.astro @@ -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' +--- + +
+ +
+
+

Sobre o Xahau

+

+ Blockchain L1 empresarial com programabilidade baseada em conta +

+
+
+ Fund. Outubro 2023 + 200k+ Contas + ~4s Liquidação + 10k tx / ledger +
+
+ + +
+

A Rede

+ + +
+
+ Visão Geral +

+ O que é o Xahau? +
+ A explicação rápida +

+

+ 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. +

+

+ 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. +

+

+ 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. +

+

+ 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. +

+
+
+ Ilustração da topologia de rede do Xahau +
+
+ + +
+
+ +
+
+
+ + +
+

+ O Protocolo +

+ + +
+
+ Tecnologia +

+ Qual é a tecnologia +
+ por trás do Xahau? +

+

+ 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. +

+

+ 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. +

+

+ 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. +

+
+
+ Ilustração da arquitetura do protocolo Xahau +
+
+
+ + +
+

+ A Moeda +

+ + +
+
+ Economia +

+ XAH, a moeda +
+ nativa do Xahau +

+

+ 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. +

+

+ 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. +

+

+ 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. +

+
+
+ Ilustração da moeda XAH +
+
+
+
+ + diff --git a/src/components/XahauConnect.astro b/src/components/XahauConnect.astro index e7645ca..e7b5996 100644 --- a/src/components/XahauConnect.astro +++ b/src/components/XahauConnect.astro @@ -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] --- diff --git a/src/components/XahauEcosystem.astro b/src/components/XahauEcosystem.astro index 198c584..d68022c 100644 --- a/src/components/XahauEcosystem.astro +++ b/src/components/XahauEcosystem.astro @@ -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 = { 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. diff --git a/src/components/XahauFeaturesPtBR.astro b/src/components/XahauFeaturesPtBR.astro new file mode 100644 index 0000000..09a12ae --- /dev/null +++ b/src/components/XahauFeaturesPtBR.astro @@ -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 +--- + +
+ +
+
+

Funcionalidades

+

Tecnologia comprovada com uma abordagem inovadora

+
+
+ 10+ Funcionalidades de Protocolo + DEX Nativa + NFTs Integrados + Sem Overhead em Tempo de Execução +
+
+ + +
+

+ Camada de Protocolo +

+ + +
+
+ Programabilidade +

+ Hooks: Lógica de +
+ Contrato Inteligente +
+ no Nível da Conta +

+

+ 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. +

+

+ 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. +

+
+
+ Hooks smart contract logic illustration +
+
+ + +
+
+ Exchange +

Offers: Exchange Descentralizado (DEX) Nativo

+

+ 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. +

+

+ 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. +

+
+ +
+ Economia +

Taxas Baixas com Queima de Taxas

+

+ 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. +

+

+ 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. +

+
+
+ + +
+ Infraestrutura +

Rápido, Verde e Escalável

+
+

+ 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. +

+

+ 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. +

+
+
+
+ + +
+

+ Primitivas Financeiras +

+ + +
+
+ Pagamentos +

+ Pagamentos: +
+ Transferências Multi-Ativo +
+ & Canais +

+

+ 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. +

+

+ 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. +

+

+ 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. +

+
+
+ Global network infrastructure illustration +
+
+ + +
+
+ Controle de Ativos +

Controle de Tokens e Ativos por Design

+

+ 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. +

+

+ 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. +

+
+ +
+ Economia +

Recompensas de Saldo: Rendimento Passivo Sem Staking

+

+ 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. +

+

+ 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. +

+
+
+ + +
+
+ Primitivas +

Escrow: Transferências Condicionais para Qualquer Ativo

+

+ 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. +

+

+ 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. +

+
+ +
+ Pagamentos +

Remit: Transferências Nativas Entre Contas

+

+ 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. +

+

+ 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. +

+
+ +
+ Pagamentos +

Checks: Sistema de Pagamento Diferido

+

+ 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. +

+

+ 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. +

+
+
+
+ + +
+

+ Governança & Identidade +

+ + +
+
+ Governança +

+ Jogo de Governança: +
+ Coordenação Descentralizada +
+ com Propósito +

+

+ 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. +

+

+ 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. +

+
+
+ Consensus mechanism illustration +
+
+ + +
+
+ NFTs +

URITokens: NFTs Nativos no Xahau

+

+ 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. +

+

+ 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. +

+
+
+
+
+ + diff --git a/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/deposit-pre-auth.mdx b/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/deposit-pre-auth.mdx deleted file mode 100644 index 46ba0aa..0000000 --- a/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/deposit-pre-auth.mdx +++ /dev/null @@ -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) diff --git a/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/directory-node.mdx b/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/directory-node.mdx deleted file mode 100644 index 3a8c266..0000000 --- a/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/directory-node.mdx +++ /dev/null @@ -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.) diff --git a/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/emitted-txn.mdx b/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/emitted-txn.mdx deleted file mode 100644 index 42d5b08..0000000 --- a/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/emitted-txn.mdx +++ /dev/null @@ -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. | diff --git a/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/escrow.mdx b/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/escrow.mdx deleted file mode 100644 index 8c445cb..0000000 --- a/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/escrow.mdx +++ /dev/null @@ -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. diff --git a/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/fee-settings.mdx b/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/fee-settings.mdx deleted file mode 100644 index d5e163c..0000000 --- a/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/fee-settings.mdx +++ /dev/null @@ -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 -``` diff --git a/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/hook-definition.mdx b/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/hook-definition.mdx deleted file mode 100644 index 734463e..0000000 --- a/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/hook-definition.mdx +++ /dev/null @@ -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 diff --git a/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/hook-state.mdx b/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/hook-state.mdx deleted file mode 100644 index e78faf6..0000000 --- a/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/hook-state.mdx +++ /dev/null @@ -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. diff --git a/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/hook.mdx b/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/hook.mdx deleted file mode 100644 index 7238950..0000000 --- a/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/hook.mdx +++ /dev/null @@ -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 diff --git a/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/import-vl-sequence.mdx b/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/import-vl-sequence.mdx deleted file mode 100644 index b068661..0000000 --- a/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/import-vl-sequence.mdx +++ /dev/null @@ -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 diff --git a/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/ledger-hashes.mdx b/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/ledger-hashes.mdx deleted file mode 100644 index 02a2acb..0000000 --- a/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/ledger-hashes.mdx +++ /dev/null @@ -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. diff --git a/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/negative-unl.mdx b/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/negative-unl.mdx deleted file mode 100644 index 612e554..0000000 --- a/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/negative-unl.mdx +++ /dev/null @@ -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 -``` diff --git a/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/offer.mdx b/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/offer.mdx deleted file mode 100644 index 3cce2ed..0000000 --- a/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/offer.mdx +++ /dev/null @@ -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: - -
Flag NameHex ValueDecimal ValueCorresponding OfferCreate FlagDescription
lsfPassive0x0001000065536tfPassiveThe object was placed as a passive Offer. This has no effect on the object in the ledger.
lsfSell0x00020000131072tfSellThe object was placed as a sell Offer. This has no effect on the object in the ledger (because tfSell only matters if you get a better rate than you asked for, which cannot happen after the object enters the ledger).
- -### 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. diff --git a/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/pay-channel.mdx b/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/pay-channel.mdx deleted file mode 100644 index e7ec5c6..0000000 --- a/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/pay-channel.mdx +++ /dev/null @@ -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. diff --git a/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/ripple-state.mdx b/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/ripple-state.mdx deleted file mode 100644 index 5bb3e18..0000000 --- a/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/ripple-state.mdx +++ /dev/null @@ -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) diff --git a/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/signers-list.mdx b/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/signers-list.mdx deleted file mode 100644 index 2c8354c..0000000 --- a/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/signers-list.mdx +++ /dev/null @@ -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`) diff --git a/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/ticket.mdx b/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/ticket.mdx deleted file mode 100644 index 0a57972..0000000 --- a/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/ticket.mdx +++ /dev/null @@ -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 diff --git a/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/unl-report.mdx b/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/unl-report.mdx deleted file mode 100644 index be49225..0000000 --- a/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/unl-report.mdx +++ /dev/null @@ -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 -``` diff --git a/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/uritoken.mdx b/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/uritoken.mdx deleted file mode 100644 index 40b87b6..0000000 --- a/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/uritoken.mdx +++ /dev/null @@ -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 diff --git a/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/accountdelete.mdx b/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/accountdelete.mdx deleted file mode 100644 index c95328b..0000000 --- a/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/accountdelete.mdx +++ /dev/null @@ -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_ - - - -### 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. | - diff --git a/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/accountset.mdx b/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/accountset.mdx deleted file mode 100644 index b425ac9..0000000 --- a/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/accountset.mdx +++ /dev/null @@ -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. - -
Flag NameHex ValueDecimal ValueReplaced by AccountSet Flag
tfRequireDestTag0x0001000065536asfRequireDest (SetFlag)
tfOptionalDestTag0x00020000131072asfRequireDest (ClearFlag)
tfRequireAuth0x00040000262144asfRequireAuth (SetFlag)
tfOptionalAuth0x00080000524288asfRequireAuth (ClearFlag)
tfDisallowXRP0x001000001048576asfDisallowXRP (SetFlag)
tfAllowXRP0x002000002097152asfDisallowXRP (ClearFlag)
- -**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. diff --git a/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/checkcancel.mdx b/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/checkcancel.mdx deleted file mode 100644 index 4138e10..0000000 --- a/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/checkcancel.mdx +++ /dev/null @@ -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`. diff --git a/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/checkcash.mdx b/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/checkcash.mdx deleted file mode 100644 index 611f14b..0000000 --- a/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/checkcash.mdx +++ /dev/null @@ -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`. diff --git a/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/checkcreate.mdx b/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/checkcreate.mdx deleted file mode 100644 index cf8c2f6..0000000 --- a/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/checkcreate.mdx +++ /dev/null @@ -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`. diff --git a/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/claimreward.mdx b/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/claimreward.mdx deleted file mode 100644 index d836534..0000000 --- a/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/claimreward.mdx +++ /dev/null @@ -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. | diff --git a/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/clawback.mdx b/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/clawback.mdx deleted file mode 100644 index d7102af..0000000 --- a/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/clawback.mdx +++ /dev/null @@ -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. | - diff --git a/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/cronset.mdx b/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/cronset.mdx deleted file mode 100644 index ed969e7..0000000 --- a/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/cronset.mdx +++ /dev/null @@ -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. | diff --git a/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/depositpreauth.mdx b/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/depositpreauth.mdx deleted file mode 100644 index 542e4e9..0000000 --- a/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/depositpreauth.mdx +++ /dev/null @@ -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'; - - - -\[[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`. diff --git a/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/escrowcancel.mdx b/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/escrowcancel.mdx deleted file mode 100644 index 568d1e9..0000000 --- a/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/escrowcancel.mdx +++ /dev/null @@ -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. diff --git a/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/escrowcreate.mdx b/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/escrowcreate.mdx deleted file mode 100644 index 601edb1..0000000 --- a/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/escrowcreate.mdx +++ /dev/null @@ -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]\[] - diff --git a/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/genesismint-emitted-txn.mdx b/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/genesismint-emitted-txn.mdx deleted file mode 100644 index 213ef81..0000000 --- a/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/genesismint-emitted-txn.mdx +++ /dev/null @@ -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. | diff --git a/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/import.mdx b/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/import.mdx deleted file mode 100644 index 52adf5f..0000000 --- a/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/import.mdx +++ /dev/null @@ -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._ diff --git a/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/invoke.mdx b/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/invoke.mdx deleted file mode 100644 index 57e6c3f..0000000 --- a/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/invoke.mdx +++ /dev/null @@ -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. | diff --git a/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/offercancel.mdx b/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/offercancel.mdx deleted file mode 100644 index 9415a18..0000000 --- a/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/offercancel.mdx +++ /dev/null @@ -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. diff --git a/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/offercreate.mdx b/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/offercreate.mdx deleted file mode 100644 index 038ac9d..0000000 --- a/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/offercreate.mdx +++ /dev/null @@ -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. | diff --git a/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/payment.mdx b/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/payment.mdx deleted file mode 100644 index fc9ed86..0000000 --- a/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/payment.mdx +++ /dev/null @@ -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. diff --git a/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/paymentchannelclaim.mdx b/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/paymentchannelclaim.mdx deleted file mode 100644 index 1dd34ae..0000000 --- a/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/paymentchannelclaim.mdx +++ /dev/null @@ -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. | diff --git a/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/paymentchannelcreate.mdx b/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/paymentchannelcreate.mdx deleted file mode 100644 index 6c87588..0000000 --- a/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/paymentchannelcreate.mdx +++ /dev/null @@ -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:)_ diff --git a/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/remit.mdx b/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/remit.mdx deleted file mode 100644 index 38b256e..0000000 --- a/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/remit.mdx +++ /dev/null @@ -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'; - - - -\[[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) | diff --git a/src/content/docs/br/docs/assets/image.png b/src/content/docs/pt-br/docs/assets/image.png similarity index 100% rename from src/content/docs/br/docs/assets/image.png rename to src/content/docs/pt-br/docs/assets/image.png diff --git a/src/content/docs/br/docs/compliance/responsible-disclosure.mdx b/src/content/docs/pt-br/docs/compliance/responsible-disclosure.mdx similarity index 100% rename from src/content/docs/br/docs/compliance/responsible-disclosure.mdx rename to src/content/docs/pt-br/docs/compliance/responsible-disclosure.mdx diff --git a/src/content/docs/br/docs/compliance/security-audit.mdx b/src/content/docs/pt-br/docs/compliance/security-audit.mdx similarity index 100% rename from src/content/docs/br/docs/compliance/security-audit.mdx rename to src/content/docs/pt-br/docs/compliance/security-audit.mdx diff --git a/src/content/docs/br/docs/data-apis/index.mdx b/src/content/docs/pt-br/docs/data-apis/index.mdx similarity index 100% rename from src/content/docs/br/docs/data-apis/index.mdx rename to src/content/docs/pt-br/docs/data-apis/index.mdx diff --git a/src/content/docs/br/docs/features/amendments.mdx b/src/content/docs/pt-br/docs/features/amendments.mdx similarity index 100% rename from src/content/docs/br/docs/features/amendments.mdx rename to src/content/docs/pt-br/docs/features/amendments.mdx diff --git a/src/content/docs/br/docs/features/balance-adjustments.mdx b/src/content/docs/pt-br/docs/features/balance-adjustments.mdx similarity index 100% rename from src/content/docs/br/docs/features/balance-adjustments.mdx rename to src/content/docs/pt-br/docs/features/balance-adjustments.mdx diff --git a/src/content/docs/br/docs/features/burn-2-mint.mdx b/src/content/docs/pt-br/docs/features/burn-2-mint.mdx similarity index 100% rename from src/content/docs/br/docs/features/burn-2-mint.mdx rename to src/content/docs/pt-br/docs/features/burn-2-mint.mdx diff --git a/src/content/docs/br/docs/features/developer-tooling/client-libraries.mdx b/src/content/docs/pt-br/docs/features/developer-tooling/client-libraries.mdx similarity index 100% rename from src/content/docs/br/docs/features/developer-tooling/client-libraries.mdx rename to src/content/docs/pt-br/docs/features/developer-tooling/client-libraries.mdx diff --git a/src/content/docs/br/docs/features/developer-tooling/curated-tooling.mdx b/src/content/docs/pt-br/docs/features/developer-tooling/curated-tooling.mdx similarity index 100% rename from src/content/docs/br/docs/features/developer-tooling/curated-tooling.mdx rename to src/content/docs/pt-br/docs/features/developer-tooling/curated-tooling.mdx diff --git a/src/content/docs/br/docs/features/developer-tooling/developer-tricks.mdx b/src/content/docs/pt-br/docs/features/developer-tooling/developer-tricks.mdx similarity index 100% rename from src/content/docs/br/docs/features/developer-tooling/developer-tricks.mdx rename to src/content/docs/pt-br/docs/features/developer-tooling/developer-tricks.mdx diff --git a/src/content/docs/br/docs/features/faucet-and-explorer.mdx b/src/content/docs/pt-br/docs/features/faucet-and-explorer.mdx similarity index 100% rename from src/content/docs/br/docs/features/faucet-and-explorer.mdx rename to src/content/docs/pt-br/docs/features/faucet-and-explorer.mdx diff --git a/src/content/docs/br/docs/features/governance-game.mdx b/src/content/docs/pt-br/docs/features/governance-game.mdx similarity index 100% rename from src/content/docs/br/docs/features/governance-game.mdx rename to src/content/docs/pt-br/docs/features/governance-game.mdx diff --git a/src/content/docs/br/docs/features/http-websocket-apis/admin-api-methods.mdx b/src/content/docs/pt-br/docs/features/http-websocket-apis/admin-api-methods.mdx similarity index 100% rename from src/content/docs/br/docs/features/http-websocket-apis/admin-api-methods.mdx rename to src/content/docs/pt-br/docs/features/http-websocket-apis/admin-api-methods.mdx diff --git a/src/content/docs/br/docs/features/http-websocket-apis/considerations.mdx b/src/content/docs/pt-br/docs/features/http-websocket-apis/considerations.mdx similarity index 100% rename from src/content/docs/br/docs/features/http-websocket-apis/considerations.mdx rename to src/content/docs/pt-br/docs/features/http-websocket-apis/considerations.mdx diff --git a/src/content/docs/br/docs/features/http-websocket-apis/public-api-methods.mdx b/src/content/docs/pt-br/docs/features/http-websocket-apis/public-api-methods.mdx similarity index 100% rename from src/content/docs/br/docs/features/http-websocket-apis/public-api-methods.mdx rename to src/content/docs/pt-br/docs/features/http-websocket-apis/public-api-methods.mdx diff --git a/src/content/docs/br/docs/features/http-websocket-apis/request-formatting-guide.mdx b/src/content/docs/pt-br/docs/features/http-websocket-apis/request-formatting-guide.mdx similarity index 100% rename from src/content/docs/br/docs/features/http-websocket-apis/request-formatting-guide.mdx rename to src/content/docs/pt-br/docs/features/http-websocket-apis/request-formatting-guide.mdx diff --git a/src/content/docs/br/docs/features/http-websocket-apis/response-formatting-guide.mdx b/src/content/docs/pt-br/docs/features/http-websocket-apis/response-formatting-guide.mdx similarity index 100% rename from src/content/docs/br/docs/features/http-websocket-apis/response-formatting-guide.mdx rename to src/content/docs/pt-br/docs/features/http-websocket-apis/response-formatting-guide.mdx diff --git a/src/content/docs/br/docs/features/network-features/account-managment.mdx b/src/content/docs/pt-br/docs/features/network-features/account-managment.mdx similarity index 100% rename from src/content/docs/br/docs/features/network-features/account-managment.mdx rename to src/content/docs/pt-br/docs/features/network-features/account-managment.mdx diff --git a/src/content/docs/br/docs/features/network-features/balance-rewards.mdx b/src/content/docs/pt-br/docs/features/network-features/balance-rewards.mdx similarity index 100% rename from src/content/docs/br/docs/features/network-features/balance-rewards.mdx rename to src/content/docs/pt-br/docs/features/network-features/balance-rewards.mdx diff --git a/src/content/docs/br/docs/features/network-features/check.mdx b/src/content/docs/pt-br/docs/features/network-features/check.mdx similarity index 100% rename from src/content/docs/br/docs/features/network-features/check.mdx rename to src/content/docs/pt-br/docs/features/network-features/check.mdx diff --git a/src/content/docs/br/docs/features/network-features/escrow.mdx b/src/content/docs/pt-br/docs/features/network-features/escrow.mdx similarity index 100% rename from src/content/docs/br/docs/features/network-features/escrow.mdx rename to src/content/docs/pt-br/docs/features/network-features/escrow.mdx diff --git a/src/content/docs/br/docs/features/network-features/hooks.mdx b/src/content/docs/pt-br/docs/features/network-features/hooks.mdx similarity index 100% rename from src/content/docs/br/docs/features/network-features/hooks.mdx rename to src/content/docs/pt-br/docs/features/network-features/hooks.mdx diff --git a/src/content/docs/br/docs/features/network-features/offer.mdx b/src/content/docs/pt-br/docs/features/network-features/offer.mdx similarity index 100% rename from src/content/docs/br/docs/features/network-features/offer.mdx rename to src/content/docs/pt-br/docs/features/network-features/offer.mdx diff --git a/src/content/docs/br/docs/features/network-features/payments.mdx b/src/content/docs/pt-br/docs/features/network-features/payments.mdx similarity index 100% rename from src/content/docs/br/docs/features/network-features/payments.mdx rename to src/content/docs/pt-br/docs/features/network-features/payments.mdx diff --git a/src/content/docs/br/docs/features/network-features/uritoken.mdx b/src/content/docs/pt-br/docs/features/network-features/uritoken.mdx similarity index 100% rename from src/content/docs/br/docs/features/network-features/uritoken.mdx rename to src/content/docs/pt-br/docs/features/network-features/uritoken.mdx diff --git a/src/content/docs/br/docs/features/public-nodes-rpc.mdx b/src/content/docs/pt-br/docs/features/public-nodes-rpc.mdx similarity index 100% rename from src/content/docs/br/docs/features/public-nodes-rpc.mdx rename to src/content/docs/pt-br/docs/features/public-nodes-rpc.mdx diff --git a/src/content/docs/br/docs/features/transaction-signing/index.mdx b/src/content/docs/pt-br/docs/features/transaction-signing/index.mdx similarity index 100% rename from src/content/docs/br/docs/features/transaction-signing/index.mdx rename to src/content/docs/pt-br/docs/features/transaction-signing/index.mdx diff --git a/src/content/docs/br/docs/features/transaction-signing/transaction-fees.mdx b/src/content/docs/pt-br/docs/features/transaction-signing/transaction-fees.mdx similarity index 100% rename from src/content/docs/br/docs/features/transaction-signing/transaction-fees.mdx rename to src/content/docs/pt-br/docs/features/transaction-signing/transaction-fees.mdx diff --git a/src/content/docs/br/docs/features/versioning-process.mdx b/src/content/docs/pt-br/docs/features/versioning-process.mdx similarity index 100% rename from src/content/docs/br/docs/features/versioning-process.mdx rename to src/content/docs/pt-br/docs/features/versioning-process.mdx diff --git a/src/content/docs/br/docs/hooks/concepts/chaining.mdx b/src/content/docs/pt-br/docs/hooks/concepts/chaining.mdx similarity index 100% rename from src/content/docs/br/docs/hooks/concepts/chaining.mdx rename to src/content/docs/pt-br/docs/hooks/concepts/chaining.mdx diff --git a/src/content/docs/br/docs/hooks/concepts/collect-call.mdx b/src/content/docs/pt-br/docs/hooks/concepts/collect-call.mdx similarity index 100% rename from src/content/docs/br/docs/hooks/concepts/collect-call.mdx rename to src/content/docs/pt-br/docs/hooks/concepts/collect-call.mdx diff --git a/src/content/docs/br/docs/hooks/concepts/compiling-hooks.mdx b/src/content/docs/pt-br/docs/hooks/concepts/compiling-hooks.mdx similarity index 100% rename from src/content/docs/br/docs/hooks/concepts/compiling-hooks.mdx rename to src/content/docs/pt-br/docs/hooks/concepts/compiling-hooks.mdx diff --git a/src/content/docs/br/docs/hooks/concepts/debugging-hooks.mdx b/src/content/docs/pt-br/docs/hooks/concepts/debugging-hooks.mdx similarity index 100% rename from src/content/docs/br/docs/hooks/concepts/debugging-hooks.mdx rename to src/content/docs/pt-br/docs/hooks/concepts/debugging-hooks.mdx diff --git a/src/content/docs/br/docs/hooks/concepts/emitted-transactions.mdx b/src/content/docs/pt-br/docs/hooks/concepts/emitted-transactions.mdx similarity index 100% rename from src/content/docs/br/docs/hooks/concepts/emitted-transactions.mdx rename to src/content/docs/pt-br/docs/hooks/concepts/emitted-transactions.mdx diff --git a/src/content/docs/br/docs/hooks/concepts/execution-metadata.mdx b/src/content/docs/pt-br/docs/hooks/concepts/execution-metadata.mdx similarity index 100% rename from src/content/docs/br/docs/hooks/concepts/execution-metadata.mdx rename to src/content/docs/pt-br/docs/hooks/concepts/execution-metadata.mdx diff --git a/src/content/docs/br/docs/hooks/concepts/floating-point-numbers-xfl.mdx b/src/content/docs/pt-br/docs/hooks/concepts/floating-point-numbers-xfl.mdx similarity index 100% rename from src/content/docs/br/docs/hooks/concepts/floating-point-numbers-xfl.mdx rename to src/content/docs/pt-br/docs/hooks/concepts/floating-point-numbers-xfl.mdx diff --git a/src/content/docs/br/docs/hooks/concepts/grants.mdx b/src/content/docs/pt-br/docs/hooks/concepts/grants.mdx similarity index 100% rename from src/content/docs/br/docs/hooks/concepts/grants.mdx rename to src/content/docs/pt-br/docs/hooks/concepts/grants.mdx diff --git a/src/content/docs/br/docs/hooks/concepts/hook-fees.mdx b/src/content/docs/pt-br/docs/hooks/concepts/hook-fees.mdx similarity index 100% rename from src/content/docs/br/docs/hooks/concepts/hook-fees.mdx rename to src/content/docs/pt-br/docs/hooks/concepts/hook-fees.mdx diff --git a/src/content/docs/br/docs/hooks/concepts/hookon-field.mdx b/src/content/docs/pt-br/docs/hooks/concepts/hookon-field.mdx similarity index 100% rename from src/content/docs/br/docs/hooks/concepts/hookon-field.mdx rename to src/content/docs/pt-br/docs/hooks/concepts/hookon-field.mdx diff --git a/src/content/docs/br/docs/hooks/concepts/introduction/example-usage.mdx b/src/content/docs/pt-br/docs/hooks/concepts/introduction/example-usage.mdx similarity index 100% rename from src/content/docs/br/docs/hooks/concepts/introduction/example-usage.mdx rename to src/content/docs/pt-br/docs/hooks/concepts/introduction/example-usage.mdx diff --git a/src/content/docs/br/docs/hooks/concepts/introduction/index.mdx b/src/content/docs/pt-br/docs/hooks/concepts/introduction/index.mdx similarity index 100% rename from src/content/docs/br/docs/hooks/concepts/introduction/index.mdx rename to src/content/docs/pt-br/docs/hooks/concepts/introduction/index.mdx diff --git a/src/content/docs/br/docs/hooks/concepts/loops-and-guarding.mdx b/src/content/docs/pt-br/docs/hooks/concepts/loops-and-guarding.mdx similarity index 100% rename from src/content/docs/br/docs/hooks/concepts/loops-and-guarding.mdx rename to src/content/docs/pt-br/docs/hooks/concepts/loops-and-guarding.mdx diff --git a/src/content/docs/br/docs/hooks/concepts/namespaces.mdx b/src/content/docs/pt-br/docs/hooks/concepts/namespaces.mdx similarity index 100% rename from src/content/docs/br/docs/hooks/concepts/namespaces.mdx rename to src/content/docs/pt-br/docs/hooks/concepts/namespaces.mdx diff --git a/src/content/docs/br/docs/hooks/concepts/parameters.mdx b/src/content/docs/pt-br/docs/hooks/concepts/parameters.mdx similarity index 100% rename from src/content/docs/br/docs/hooks/concepts/parameters.mdx rename to src/content/docs/pt-br/docs/hooks/concepts/parameters.mdx diff --git a/src/content/docs/br/docs/hooks/concepts/reference-counted-hook-definitions.mdx b/src/content/docs/pt-br/docs/hooks/concepts/reference-counted-hook-definitions.mdx similarity index 100% rename from src/content/docs/br/docs/hooks/concepts/reference-counted-hook-definitions.mdx rename to src/content/docs/pt-br/docs/hooks/concepts/reference-counted-hook-definitions.mdx diff --git a/src/content/docs/br/docs/hooks/concepts/serialized-objects.mdx b/src/content/docs/pt-br/docs/hooks/concepts/serialized-objects.mdx similarity index 100% rename from src/content/docs/br/docs/hooks/concepts/serialized-objects.mdx rename to src/content/docs/pt-br/docs/hooks/concepts/serialized-objects.mdx diff --git a/src/content/docs/br/docs/hooks/concepts/sethook-transaction.mdx b/src/content/docs/pt-br/docs/hooks/concepts/sethook-transaction.mdx similarity index 100% rename from src/content/docs/br/docs/hooks/concepts/sethook-transaction.mdx rename to src/content/docs/pt-br/docs/hooks/concepts/sethook-transaction.mdx diff --git a/src/content/docs/br/docs/hooks/concepts/slots-and-keylets.mdx b/src/content/docs/pt-br/docs/hooks/concepts/slots-and-keylets.mdx similarity index 100% rename from src/content/docs/br/docs/hooks/concepts/slots-and-keylets.mdx rename to src/content/docs/pt-br/docs/hooks/concepts/slots-and-keylets.mdx diff --git a/src/content/docs/br/docs/hooks/concepts/state-management.mdx b/src/content/docs/pt-br/docs/hooks/concepts/state-management.mdx similarity index 100% rename from src/content/docs/br/docs/hooks/concepts/state-management.mdx rename to src/content/docs/pt-br/docs/hooks/concepts/state-management.mdx diff --git a/src/content/docs/br/docs/hooks/concepts/terminology.mdx b/src/content/docs/pt-br/docs/hooks/concepts/terminology.mdx similarity index 100% rename from src/content/docs/br/docs/hooks/concepts/terminology.mdx rename to src/content/docs/pt-br/docs/hooks/concepts/terminology.mdx diff --git a/src/content/docs/br/docs/hooks/concepts/weak-and-strong.mdx b/src/content/docs/pt-br/docs/hooks/concepts/weak-and-strong.mdx similarity index 100% rename from src/content/docs/br/docs/hooks/concepts/weak-and-strong.mdx rename to src/content/docs/pt-br/docs/hooks/concepts/weak-and-strong.mdx diff --git a/src/content/docs/br/docs/hooks/functions/control/accept.mdx b/src/content/docs/pt-br/docs/hooks/functions/control/accept.mdx similarity index 100% rename from src/content/docs/br/docs/hooks/functions/control/accept.mdx rename to src/content/docs/pt-br/docs/hooks/functions/control/accept.mdx diff --git a/src/content/docs/br/docs/hooks/functions/control/rollback.mdx b/src/content/docs/pt-br/docs/hooks/functions/control/rollback.mdx similarity index 100% rename from src/content/docs/br/docs/hooks/functions/control/rollback.mdx rename to src/content/docs/pt-br/docs/hooks/functions/control/rollback.mdx diff --git a/src/content/docs/br/docs/hooks/functions/developer-defined/cbak-callback.mdx b/src/content/docs/pt-br/docs/hooks/functions/developer-defined/cbak-callback.mdx similarity index 100% rename from src/content/docs/br/docs/hooks/functions/developer-defined/cbak-callback.mdx rename to src/content/docs/pt-br/docs/hooks/functions/developer-defined/cbak-callback.mdx diff --git a/src/content/docs/br/docs/hooks/functions/developer-defined/hook.mdx b/src/content/docs/pt-br/docs/hooks/functions/developer-defined/hook.mdx similarity index 100% rename from src/content/docs/br/docs/hooks/functions/developer-defined/hook.mdx rename to src/content/docs/pt-br/docs/hooks/functions/developer-defined/hook.mdx diff --git a/src/content/docs/br/docs/hooks/functions/emitted-transaction/emit-1.mdx b/src/content/docs/pt-br/docs/hooks/functions/emitted-transaction/emit-1.mdx similarity index 100% rename from src/content/docs/br/docs/hooks/functions/emitted-transaction/emit-1.mdx rename to src/content/docs/pt-br/docs/hooks/functions/emitted-transaction/emit-1.mdx diff --git a/src/content/docs/br/docs/hooks/functions/emitted-transaction/emit.mdx b/src/content/docs/pt-br/docs/hooks/functions/emitted-transaction/emit.mdx similarity index 100% rename from src/content/docs/br/docs/hooks/functions/emitted-transaction/emit.mdx rename to src/content/docs/pt-br/docs/hooks/functions/emitted-transaction/emit.mdx diff --git a/src/content/docs/br/docs/hooks/functions/emitted-transaction/etxn_burden.mdx b/src/content/docs/pt-br/docs/hooks/functions/emitted-transaction/etxn_burden.mdx similarity index 100% rename from src/content/docs/br/docs/hooks/functions/emitted-transaction/etxn_burden.mdx rename to src/content/docs/pt-br/docs/hooks/functions/emitted-transaction/etxn_burden.mdx diff --git a/src/content/docs/br/docs/hooks/functions/emitted-transaction/etxn_details.mdx b/src/content/docs/pt-br/docs/hooks/functions/emitted-transaction/etxn_details.mdx similarity index 100% rename from src/content/docs/br/docs/hooks/functions/emitted-transaction/etxn_details.mdx rename to src/content/docs/pt-br/docs/hooks/functions/emitted-transaction/etxn_details.mdx diff --git a/src/content/docs/br/docs/hooks/functions/emitted-transaction/etxn_fee_base.mdx b/src/content/docs/pt-br/docs/hooks/functions/emitted-transaction/etxn_fee_base.mdx similarity index 100% rename from src/content/docs/br/docs/hooks/functions/emitted-transaction/etxn_fee_base.mdx rename to src/content/docs/pt-br/docs/hooks/functions/emitted-transaction/etxn_fee_base.mdx diff --git a/src/content/docs/br/docs/hooks/functions/emitted-transaction/etxn_generation.mdx b/src/content/docs/pt-br/docs/hooks/functions/emitted-transaction/etxn_generation.mdx similarity index 100% rename from src/content/docs/br/docs/hooks/functions/emitted-transaction/etxn_generation.mdx rename to src/content/docs/pt-br/docs/hooks/functions/emitted-transaction/etxn_generation.mdx diff --git a/src/content/docs/br/docs/hooks/functions/emitted-transaction/etxn_nonce.mdx b/src/content/docs/pt-br/docs/hooks/functions/emitted-transaction/etxn_nonce.mdx similarity index 100% rename from src/content/docs/br/docs/hooks/functions/emitted-transaction/etxn_nonce.mdx rename to src/content/docs/pt-br/docs/hooks/functions/emitted-transaction/etxn_nonce.mdx diff --git a/src/content/docs/br/docs/hooks/functions/emitted-transaction/etxn_reserve.mdx b/src/content/docs/pt-br/docs/hooks/functions/emitted-transaction/etxn_reserve.mdx similarity index 100% rename from src/content/docs/br/docs/hooks/functions/emitted-transaction/etxn_reserve.mdx rename to src/content/docs/pt-br/docs/hooks/functions/emitted-transaction/etxn_reserve.mdx diff --git a/src/content/docs/br/docs/hooks/functions/float/float_compare.mdx b/src/content/docs/pt-br/docs/hooks/functions/float/float_compare.mdx similarity index 100% rename from src/content/docs/br/docs/hooks/functions/float/float_compare.mdx rename to src/content/docs/pt-br/docs/hooks/functions/float/float_compare.mdx diff --git a/src/content/docs/br/docs/hooks/functions/float/float_divide.mdx b/src/content/docs/pt-br/docs/hooks/functions/float/float_divide.mdx similarity index 100% rename from src/content/docs/br/docs/hooks/functions/float/float_divide.mdx rename to src/content/docs/pt-br/docs/hooks/functions/float/float_divide.mdx diff --git a/src/content/docs/br/docs/hooks/functions/float/float_exponent.mdx b/src/content/docs/pt-br/docs/hooks/functions/float/float_exponent.mdx similarity index 100% rename from src/content/docs/br/docs/hooks/functions/float/float_exponent.mdx rename to src/content/docs/pt-br/docs/hooks/functions/float/float_exponent.mdx diff --git a/src/content/docs/br/docs/hooks/functions/float/float_int.mdx b/src/content/docs/pt-br/docs/hooks/functions/float/float_int.mdx similarity index 100% rename from src/content/docs/br/docs/hooks/functions/float/float_int.mdx rename to src/content/docs/pt-br/docs/hooks/functions/float/float_int.mdx diff --git a/src/content/docs/br/docs/hooks/functions/float/float_invert.mdx b/src/content/docs/pt-br/docs/hooks/functions/float/float_invert.mdx similarity index 100% rename from src/content/docs/br/docs/hooks/functions/float/float_invert.mdx rename to src/content/docs/pt-br/docs/hooks/functions/float/float_invert.mdx diff --git a/src/content/docs/br/docs/hooks/functions/float/float_log.mdx b/src/content/docs/pt-br/docs/hooks/functions/float/float_log.mdx similarity index 100% rename from src/content/docs/br/docs/hooks/functions/float/float_log.mdx rename to src/content/docs/pt-br/docs/hooks/functions/float/float_log.mdx diff --git a/src/content/docs/br/docs/hooks/functions/float/float_mantissa.mdx b/src/content/docs/pt-br/docs/hooks/functions/float/float_mantissa.mdx similarity index 100% rename from src/content/docs/br/docs/hooks/functions/float/float_mantissa.mdx rename to src/content/docs/pt-br/docs/hooks/functions/float/float_mantissa.mdx diff --git a/src/content/docs/br/docs/hooks/functions/float/float_mulratio.mdx b/src/content/docs/pt-br/docs/hooks/functions/float/float_mulratio.mdx similarity index 100% rename from src/content/docs/br/docs/hooks/functions/float/float_mulratio.mdx rename to src/content/docs/pt-br/docs/hooks/functions/float/float_mulratio.mdx diff --git a/src/content/docs/br/docs/hooks/functions/float/float_multiply.mdx b/src/content/docs/pt-br/docs/hooks/functions/float/float_multiply.mdx similarity index 100% rename from src/content/docs/br/docs/hooks/functions/float/float_multiply.mdx rename to src/content/docs/pt-br/docs/hooks/functions/float/float_multiply.mdx diff --git a/src/content/docs/br/docs/hooks/functions/float/float_negate.mdx b/src/content/docs/pt-br/docs/hooks/functions/float/float_negate.mdx similarity index 100% rename from src/content/docs/br/docs/hooks/functions/float/float_negate.mdx rename to src/content/docs/pt-br/docs/hooks/functions/float/float_negate.mdx diff --git a/src/content/docs/br/docs/hooks/functions/float/float_one.mdx b/src/content/docs/pt-br/docs/hooks/functions/float/float_one.mdx similarity index 100% rename from src/content/docs/br/docs/hooks/functions/float/float_one.mdx rename to src/content/docs/pt-br/docs/hooks/functions/float/float_one.mdx diff --git a/src/content/docs/br/docs/hooks/functions/float/float_root.mdx b/src/content/docs/pt-br/docs/hooks/functions/float/float_root.mdx similarity index 100% rename from src/content/docs/br/docs/hooks/functions/float/float_root.mdx rename to src/content/docs/pt-br/docs/hooks/functions/float/float_root.mdx diff --git a/src/content/docs/br/docs/hooks/functions/float/float_set.mdx b/src/content/docs/pt-br/docs/hooks/functions/float/float_set.mdx similarity index 100% rename from src/content/docs/br/docs/hooks/functions/float/float_set.mdx rename to src/content/docs/pt-br/docs/hooks/functions/float/float_set.mdx diff --git a/src/content/docs/br/docs/hooks/functions/float/float_sign.mdx b/src/content/docs/pt-br/docs/hooks/functions/float/float_sign.mdx similarity index 100% rename from src/content/docs/br/docs/hooks/functions/float/float_sign.mdx rename to src/content/docs/pt-br/docs/hooks/functions/float/float_sign.mdx diff --git a/src/content/docs/br/docs/hooks/functions/float/float_sto.mdx b/src/content/docs/pt-br/docs/hooks/functions/float/float_sto.mdx similarity index 100% rename from src/content/docs/br/docs/hooks/functions/float/float_sto.mdx rename to src/content/docs/pt-br/docs/hooks/functions/float/float_sto.mdx diff --git a/src/content/docs/br/docs/hooks/functions/float/float_sto_set.mdx b/src/content/docs/pt-br/docs/hooks/functions/float/float_sto_set.mdx similarity index 100% rename from src/content/docs/br/docs/hooks/functions/float/float_sto_set.mdx rename to src/content/docs/pt-br/docs/hooks/functions/float/float_sto_set.mdx diff --git a/src/content/docs/br/docs/hooks/functions/float/float_sum.mdx b/src/content/docs/pt-br/docs/hooks/functions/float/float_sum.mdx similarity index 100% rename from src/content/docs/br/docs/hooks/functions/float/float_sum.mdx rename to src/content/docs/pt-br/docs/hooks/functions/float/float_sum.mdx diff --git a/src/content/docs/br/docs/hooks/functions/hook-context/hook_account.mdx b/src/content/docs/pt-br/docs/hooks/functions/hook-context/hook_account.mdx similarity index 100% rename from src/content/docs/br/docs/hooks/functions/hook-context/hook_account.mdx rename to src/content/docs/pt-br/docs/hooks/functions/hook-context/hook_account.mdx diff --git a/src/content/docs/br/docs/hooks/functions/hook-context/hook_again.mdx b/src/content/docs/pt-br/docs/hooks/functions/hook-context/hook_again.mdx similarity index 100% rename from src/content/docs/br/docs/hooks/functions/hook-context/hook_again.mdx rename to src/content/docs/pt-br/docs/hooks/functions/hook-context/hook_again.mdx diff --git a/src/content/docs/br/docs/hooks/functions/hook-context/hook_hash.mdx b/src/content/docs/pt-br/docs/hooks/functions/hook-context/hook_hash.mdx similarity index 100% rename from src/content/docs/br/docs/hooks/functions/hook-context/hook_hash.mdx rename to src/content/docs/pt-br/docs/hooks/functions/hook-context/hook_hash.mdx diff --git a/src/content/docs/br/docs/hooks/functions/hook-context/hook_param.mdx b/src/content/docs/pt-br/docs/hooks/functions/hook-context/hook_param.mdx similarity index 100% rename from src/content/docs/br/docs/hooks/functions/hook-context/hook_param.mdx rename to src/content/docs/pt-br/docs/hooks/functions/hook-context/hook_param.mdx diff --git a/src/content/docs/br/docs/hooks/functions/hook-context/hook_param_set.mdx b/src/content/docs/pt-br/docs/hooks/functions/hook-context/hook_param_set.mdx similarity index 100% rename from src/content/docs/br/docs/hooks/functions/hook-context/hook_param_set.mdx rename to src/content/docs/pt-br/docs/hooks/functions/hook-context/hook_param_set.mdx diff --git a/src/content/docs/br/docs/hooks/functions/hook-context/hook_pos.mdx b/src/content/docs/pt-br/docs/hooks/functions/hook-context/hook_pos.mdx similarity index 100% rename from src/content/docs/br/docs/hooks/functions/hook-context/hook_pos.mdx rename to src/content/docs/pt-br/docs/hooks/functions/hook-context/hook_pos.mdx diff --git a/src/content/docs/br/docs/hooks/functions/hook-context/hook_skip.mdx b/src/content/docs/pt-br/docs/hooks/functions/hook-context/hook_skip.mdx similarity index 100% rename from src/content/docs/br/docs/hooks/functions/hook-context/hook_skip.mdx rename to src/content/docs/pt-br/docs/hooks/functions/hook-context/hook_skip.mdx diff --git a/src/content/docs/br/docs/hooks/functions/ledger/fee_base.mdx b/src/content/docs/pt-br/docs/hooks/functions/ledger/fee_base.mdx similarity index 100% rename from src/content/docs/br/docs/hooks/functions/ledger/fee_base.mdx rename to src/content/docs/pt-br/docs/hooks/functions/ledger/fee_base.mdx diff --git a/src/content/docs/br/docs/hooks/functions/ledger/ledger_keylet.mdx b/src/content/docs/pt-br/docs/hooks/functions/ledger/ledger_keylet.mdx similarity index 100% rename from src/content/docs/br/docs/hooks/functions/ledger/ledger_keylet.mdx rename to src/content/docs/pt-br/docs/hooks/functions/ledger/ledger_keylet.mdx diff --git a/src/content/docs/br/docs/hooks/functions/ledger/ledger_last_hash.mdx b/src/content/docs/pt-br/docs/hooks/functions/ledger/ledger_last_hash.mdx similarity index 100% rename from src/content/docs/br/docs/hooks/functions/ledger/ledger_last_hash.mdx rename to src/content/docs/pt-br/docs/hooks/functions/ledger/ledger_last_hash.mdx diff --git a/src/content/docs/br/docs/hooks/functions/ledger/ledger_last_time.mdx b/src/content/docs/pt-br/docs/hooks/functions/ledger/ledger_last_time.mdx similarity index 100% rename from src/content/docs/br/docs/hooks/functions/ledger/ledger_last_time.mdx rename to src/content/docs/pt-br/docs/hooks/functions/ledger/ledger_last_time.mdx diff --git a/src/content/docs/br/docs/hooks/functions/ledger/ledger_nonce.mdx b/src/content/docs/pt-br/docs/hooks/functions/ledger/ledger_nonce.mdx similarity index 100% rename from src/content/docs/br/docs/hooks/functions/ledger/ledger_nonce.mdx rename to src/content/docs/pt-br/docs/hooks/functions/ledger/ledger_nonce.mdx diff --git a/src/content/docs/br/docs/hooks/functions/ledger/ledger_seq.mdx b/src/content/docs/pt-br/docs/hooks/functions/ledger/ledger_seq.mdx similarity index 100% rename from src/content/docs/br/docs/hooks/functions/ledger/ledger_seq.mdx rename to src/content/docs/pt-br/docs/hooks/functions/ledger/ledger_seq.mdx diff --git a/src/content/docs/br/docs/hooks/functions/originating-transaction/meta_slot.mdx b/src/content/docs/pt-br/docs/hooks/functions/originating-transaction/meta_slot.mdx similarity index 100% rename from src/content/docs/br/docs/hooks/functions/originating-transaction/meta_slot.mdx rename to src/content/docs/pt-br/docs/hooks/functions/originating-transaction/meta_slot.mdx diff --git a/src/content/docs/br/docs/hooks/functions/originating-transaction/otxn_burden.mdx b/src/content/docs/pt-br/docs/hooks/functions/originating-transaction/otxn_burden.mdx similarity index 100% rename from src/content/docs/br/docs/hooks/functions/originating-transaction/otxn_burden.mdx rename to src/content/docs/pt-br/docs/hooks/functions/originating-transaction/otxn_burden.mdx diff --git a/src/content/docs/br/docs/hooks/functions/originating-transaction/otxn_field.mdx b/src/content/docs/pt-br/docs/hooks/functions/originating-transaction/otxn_field.mdx similarity index 100% rename from src/content/docs/br/docs/hooks/functions/originating-transaction/otxn_field.mdx rename to src/content/docs/pt-br/docs/hooks/functions/originating-transaction/otxn_field.mdx diff --git a/src/content/docs/br/docs/hooks/functions/originating-transaction/otxn_generation.mdx b/src/content/docs/pt-br/docs/hooks/functions/originating-transaction/otxn_generation.mdx similarity index 100% rename from src/content/docs/br/docs/hooks/functions/originating-transaction/otxn_generation.mdx rename to src/content/docs/pt-br/docs/hooks/functions/originating-transaction/otxn_generation.mdx diff --git a/src/content/docs/br/docs/hooks/functions/originating-transaction/otxn_id.mdx b/src/content/docs/pt-br/docs/hooks/functions/originating-transaction/otxn_id.mdx similarity index 100% rename from src/content/docs/br/docs/hooks/functions/originating-transaction/otxn_id.mdx rename to src/content/docs/pt-br/docs/hooks/functions/originating-transaction/otxn_id.mdx diff --git a/src/content/docs/br/docs/hooks/functions/originating-transaction/otxn_json.mdx b/src/content/docs/pt-br/docs/hooks/functions/originating-transaction/otxn_json.mdx similarity index 100% rename from src/content/docs/br/docs/hooks/functions/originating-transaction/otxn_json.mdx rename to src/content/docs/pt-br/docs/hooks/functions/originating-transaction/otxn_json.mdx diff --git a/src/content/docs/br/docs/hooks/functions/originating-transaction/otxn_param.mdx b/src/content/docs/pt-br/docs/hooks/functions/originating-transaction/otxn_param.mdx similarity index 100% rename from src/content/docs/br/docs/hooks/functions/originating-transaction/otxn_param.mdx rename to src/content/docs/pt-br/docs/hooks/functions/originating-transaction/otxn_param.mdx diff --git a/src/content/docs/br/docs/hooks/functions/originating-transaction/otxn_slot.mdx b/src/content/docs/pt-br/docs/hooks/functions/originating-transaction/otxn_slot.mdx similarity index 100% rename from src/content/docs/br/docs/hooks/functions/originating-transaction/otxn_slot.mdx rename to src/content/docs/pt-br/docs/hooks/functions/originating-transaction/otxn_slot.mdx diff --git a/src/content/docs/br/docs/hooks/functions/originating-transaction/otxn_type.mdx b/src/content/docs/pt-br/docs/hooks/functions/originating-transaction/otxn_type.mdx similarity index 100% rename from src/content/docs/br/docs/hooks/functions/originating-transaction/otxn_type.mdx rename to src/content/docs/pt-br/docs/hooks/functions/originating-transaction/otxn_type.mdx diff --git a/src/content/docs/br/docs/hooks/functions/overview/hook-api-conventions.mdx b/src/content/docs/pt-br/docs/hooks/functions/overview/hook-api-conventions.mdx similarity index 100% rename from src/content/docs/br/docs/hooks/functions/overview/hook-api-conventions.mdx rename to src/content/docs/pt-br/docs/hooks/functions/overview/hook-api-conventions.mdx diff --git a/src/content/docs/br/docs/hooks/functions/overview/return-codes.mdx b/src/content/docs/pt-br/docs/hooks/functions/overview/return-codes.mdx similarity index 100% rename from src/content/docs/br/docs/hooks/functions/overview/return-codes.mdx rename to src/content/docs/pt-br/docs/hooks/functions/overview/return-codes.mdx diff --git a/src/content/docs/br/docs/hooks/functions/serialization/sto_emplace.mdx b/src/content/docs/pt-br/docs/hooks/functions/serialization/sto_emplace.mdx similarity index 100% rename from src/content/docs/br/docs/hooks/functions/serialization/sto_emplace.mdx rename to src/content/docs/pt-br/docs/hooks/functions/serialization/sto_emplace.mdx diff --git a/src/content/docs/br/docs/hooks/functions/serialization/sto_erase.mdx b/src/content/docs/pt-br/docs/hooks/functions/serialization/sto_erase.mdx similarity index 100% rename from src/content/docs/br/docs/hooks/functions/serialization/sto_erase.mdx rename to src/content/docs/pt-br/docs/hooks/functions/serialization/sto_erase.mdx diff --git a/src/content/docs/br/docs/hooks/functions/serialization/sto_from_json.mdx b/src/content/docs/pt-br/docs/hooks/functions/serialization/sto_from_json.mdx similarity index 100% rename from src/content/docs/br/docs/hooks/functions/serialization/sto_from_json.mdx rename to src/content/docs/pt-br/docs/hooks/functions/serialization/sto_from_json.mdx diff --git a/src/content/docs/br/docs/hooks/functions/serialization/sto_subarray.mdx b/src/content/docs/pt-br/docs/hooks/functions/serialization/sto_subarray.mdx similarity index 100% rename from src/content/docs/br/docs/hooks/functions/serialization/sto_subarray.mdx rename to src/content/docs/pt-br/docs/hooks/functions/serialization/sto_subarray.mdx diff --git a/src/content/docs/br/docs/hooks/functions/serialization/sto_subfield.mdx b/src/content/docs/pt-br/docs/hooks/functions/serialization/sto_subfield.mdx similarity index 100% rename from src/content/docs/br/docs/hooks/functions/serialization/sto_subfield.mdx rename to src/content/docs/pt-br/docs/hooks/functions/serialization/sto_subfield.mdx diff --git a/src/content/docs/br/docs/hooks/functions/serialization/sto_to_json.mdx b/src/content/docs/pt-br/docs/hooks/functions/serialization/sto_to_json.mdx similarity index 100% rename from src/content/docs/br/docs/hooks/functions/serialization/sto_to_json.mdx rename to src/content/docs/pt-br/docs/hooks/functions/serialization/sto_to_json.mdx diff --git a/src/content/docs/br/docs/hooks/functions/serialization/sto_validate.mdx b/src/content/docs/pt-br/docs/hooks/functions/serialization/sto_validate.mdx similarity index 100% rename from src/content/docs/br/docs/hooks/functions/serialization/sto_validate.mdx rename to src/content/docs/pt-br/docs/hooks/functions/serialization/sto_validate.mdx diff --git a/src/content/docs/br/docs/hooks/functions/slot/slot.mdx b/src/content/docs/pt-br/docs/hooks/functions/slot/slot.mdx similarity index 100% rename from src/content/docs/br/docs/hooks/functions/slot/slot.mdx rename to src/content/docs/pt-br/docs/hooks/functions/slot/slot.mdx diff --git a/src/content/docs/br/docs/hooks/functions/slot/slot_clear.mdx b/src/content/docs/pt-br/docs/hooks/functions/slot/slot_clear.mdx similarity index 100% rename from src/content/docs/br/docs/hooks/functions/slot/slot_clear.mdx rename to src/content/docs/pt-br/docs/hooks/functions/slot/slot_clear.mdx diff --git a/src/content/docs/br/docs/hooks/functions/slot/slot_count.mdx b/src/content/docs/pt-br/docs/hooks/functions/slot/slot_count.mdx similarity index 100% rename from src/content/docs/br/docs/hooks/functions/slot/slot_count.mdx rename to src/content/docs/pt-br/docs/hooks/functions/slot/slot_count.mdx diff --git a/src/content/docs/br/docs/hooks/functions/slot/slot_float.mdx b/src/content/docs/pt-br/docs/hooks/functions/slot/slot_float.mdx similarity index 100% rename from src/content/docs/br/docs/hooks/functions/slot/slot_float.mdx rename to src/content/docs/pt-br/docs/hooks/functions/slot/slot_float.mdx diff --git a/src/content/docs/br/docs/hooks/functions/slot/slot_set.mdx b/src/content/docs/pt-br/docs/hooks/functions/slot/slot_set.mdx similarity index 100% rename from src/content/docs/br/docs/hooks/functions/slot/slot_set.mdx rename to src/content/docs/pt-br/docs/hooks/functions/slot/slot_set.mdx diff --git a/src/content/docs/br/docs/hooks/functions/slot/slot_size.mdx b/src/content/docs/pt-br/docs/hooks/functions/slot/slot_size.mdx similarity index 100% rename from src/content/docs/br/docs/hooks/functions/slot/slot_size.mdx rename to src/content/docs/pt-br/docs/hooks/functions/slot/slot_size.mdx diff --git a/src/content/docs/br/docs/hooks/functions/slot/slot_subarray.mdx b/src/content/docs/pt-br/docs/hooks/functions/slot/slot_subarray.mdx similarity index 100% rename from src/content/docs/br/docs/hooks/functions/slot/slot_subarray.mdx rename to src/content/docs/pt-br/docs/hooks/functions/slot/slot_subarray.mdx diff --git a/src/content/docs/br/docs/hooks/functions/slot/slot_subfield.mdx b/src/content/docs/pt-br/docs/hooks/functions/slot/slot_subfield.mdx similarity index 100% rename from src/content/docs/br/docs/hooks/functions/slot/slot_subfield.mdx rename to src/content/docs/pt-br/docs/hooks/functions/slot/slot_subfield.mdx diff --git a/src/content/docs/br/docs/hooks/functions/slot/slot_type.mdx b/src/content/docs/pt-br/docs/hooks/functions/slot/slot_type.mdx similarity index 100% rename from src/content/docs/br/docs/hooks/functions/slot/slot_type.mdx rename to src/content/docs/pt-br/docs/hooks/functions/slot/slot_type.mdx diff --git a/src/content/docs/br/docs/hooks/functions/slot/xpop_slot.mdx b/src/content/docs/pt-br/docs/hooks/functions/slot/xpop_slot.mdx similarity index 100% rename from src/content/docs/br/docs/hooks/functions/slot/xpop_slot.mdx rename to src/content/docs/pt-br/docs/hooks/functions/slot/xpop_slot.mdx diff --git a/src/content/docs/br/docs/hooks/functions/state/state.mdx b/src/content/docs/pt-br/docs/hooks/functions/state/state.mdx similarity index 100% rename from src/content/docs/br/docs/hooks/functions/state/state.mdx rename to src/content/docs/pt-br/docs/hooks/functions/state/state.mdx diff --git a/src/content/docs/br/docs/hooks/functions/state/state_foreign.mdx b/src/content/docs/pt-br/docs/hooks/functions/state/state_foreign.mdx similarity index 100% rename from src/content/docs/br/docs/hooks/functions/state/state_foreign.mdx rename to src/content/docs/pt-br/docs/hooks/functions/state/state_foreign.mdx diff --git a/src/content/docs/br/docs/hooks/functions/state/state_foreign_set.mdx b/src/content/docs/pt-br/docs/hooks/functions/state/state_foreign_set.mdx similarity index 100% rename from src/content/docs/br/docs/hooks/functions/state/state_foreign_set.mdx rename to src/content/docs/pt-br/docs/hooks/functions/state/state_foreign_set.mdx diff --git a/src/content/docs/br/docs/hooks/functions/state/state_set.mdx b/src/content/docs/pt-br/docs/hooks/functions/state/state_set.mdx similarity index 100% rename from src/content/docs/br/docs/hooks/functions/state/state_set.mdx rename to src/content/docs/pt-br/docs/hooks/functions/state/state_set.mdx diff --git a/src/content/docs/br/docs/hooks/functions/trace-debug/trace.mdx b/src/content/docs/pt-br/docs/hooks/functions/trace-debug/trace.mdx similarity index 100% rename from src/content/docs/br/docs/hooks/functions/trace-debug/trace.mdx rename to src/content/docs/pt-br/docs/hooks/functions/trace-debug/trace.mdx diff --git a/src/content/docs/br/docs/hooks/functions/trace-debug/trace_float.mdx b/src/content/docs/pt-br/docs/hooks/functions/trace-debug/trace_float.mdx similarity index 100% rename from src/content/docs/br/docs/hooks/functions/trace-debug/trace_float.mdx rename to src/content/docs/pt-br/docs/hooks/functions/trace-debug/trace_float.mdx diff --git a/src/content/docs/br/docs/hooks/functions/trace-debug/trace_num.mdx b/src/content/docs/pt-br/docs/hooks/functions/trace-debug/trace_num.mdx similarity index 100% rename from src/content/docs/br/docs/hooks/functions/trace-debug/trace_num.mdx rename to src/content/docs/pt-br/docs/hooks/functions/trace-debug/trace_num.mdx diff --git a/src/content/docs/br/docs/hooks/functions/utilities/util_accid.mdx b/src/content/docs/pt-br/docs/hooks/functions/utilities/util_accid.mdx similarity index 100% rename from src/content/docs/br/docs/hooks/functions/utilities/util_accid.mdx rename to src/content/docs/pt-br/docs/hooks/functions/utilities/util_accid.mdx diff --git a/src/content/docs/br/docs/hooks/functions/utilities/util_keylet.mdx b/src/content/docs/pt-br/docs/hooks/functions/utilities/util_keylet.mdx similarity index 100% rename from src/content/docs/br/docs/hooks/functions/utilities/util_keylet.mdx rename to src/content/docs/pt-br/docs/hooks/functions/utilities/util_keylet.mdx diff --git a/src/content/docs/br/docs/hooks/functions/utilities/util_raddr.mdx b/src/content/docs/pt-br/docs/hooks/functions/utilities/util_raddr.mdx similarity index 100% rename from src/content/docs/br/docs/hooks/functions/utilities/util_raddr.mdx rename to src/content/docs/pt-br/docs/hooks/functions/utilities/util_raddr.mdx diff --git a/src/content/docs/br/docs/hooks/functions/utilities/util_sha512h.mdx b/src/content/docs/pt-br/docs/hooks/functions/utilities/util_sha512h.mdx similarity index 100% rename from src/content/docs/br/docs/hooks/functions/utilities/util_sha512h.mdx rename to src/content/docs/pt-br/docs/hooks/functions/utilities/util_sha512h.mdx diff --git a/src/content/docs/br/docs/hooks/functions/utilities/util_verify.mdx b/src/content/docs/pt-br/docs/hooks/functions/utilities/util_verify.mdx similarity index 100% rename from src/content/docs/br/docs/hooks/functions/utilities/util_verify.mdx rename to src/content/docs/pt-br/docs/hooks/functions/utilities/util_verify.mdx diff --git a/src/content/docs/br/docs/hooks/functions/websocket-apis/account_info.mdx b/src/content/docs/pt-br/docs/hooks/functions/websocket-apis/account_info.mdx similarity index 100% rename from src/content/docs/br/docs/hooks/functions/websocket-apis/account_info.mdx rename to src/content/docs/pt-br/docs/hooks/functions/websocket-apis/account_info.mdx diff --git a/src/content/docs/br/docs/hooks/functions/websocket-apis/account_namespace.mdx b/src/content/docs/pt-br/docs/hooks/functions/websocket-apis/account_namespace.mdx similarity index 100% rename from src/content/docs/br/docs/hooks/functions/websocket-apis/account_namespace.mdx rename to src/content/docs/pt-br/docs/hooks/functions/websocket-apis/account_namespace.mdx diff --git a/src/content/docs/br/docs/hooks/index.mdx b/src/content/docs/pt-br/docs/hooks/index.mdx similarity index 100% rename from src/content/docs/br/docs/hooks/index.mdx rename to src/content/docs/pt-br/docs/hooks/index.mdx diff --git a/src/content/docs/br/docs/index.mdx b/src/content/docs/pt-br/docs/index.mdx similarity index 100% rename from src/content/docs/br/docs/index.mdx rename to src/content/docs/pt-br/docs/index.mdx diff --git a/src/content/docs/br/docs/infrastructure/advanced-configuration.mdx b/src/content/docs/pt-br/docs/infrastructure/advanced-configuration.mdx similarity index 100% rename from src/content/docs/br/docs/infrastructure/advanced-configuration.mdx rename to src/content/docs/pt-br/docs/infrastructure/advanced-configuration.mdx diff --git a/src/content/docs/br/docs/infrastructure/build-xahaud/index.mdx b/src/content/docs/pt-br/docs/infrastructure/build-xahaud/index.mdx similarity index 100% rename from src/content/docs/br/docs/infrastructure/build-xahaud/index.mdx rename to src/content/docs/pt-br/docs/infrastructure/build-xahaud/index.mdx diff --git a/src/content/docs/br/docs/infrastructure/build-xahaud/linux.mdx b/src/content/docs/pt-br/docs/infrastructure/build-xahaud/linux.mdx similarity index 100% rename from src/content/docs/br/docs/infrastructure/build-xahaud/linux.mdx rename to src/content/docs/pt-br/docs/infrastructure/build-xahaud/linux.mdx diff --git a/src/content/docs/br/docs/infrastructure/build-xahaud/macos.mdx b/src/content/docs/pt-br/docs/infrastructure/build-xahaud/macos.mdx similarity index 100% rename from src/content/docs/br/docs/infrastructure/build-xahaud/macos.mdx rename to src/content/docs/pt-br/docs/infrastructure/build-xahaud/macos.mdx diff --git a/src/content/docs/br/docs/infrastructure/enabling-validation.mdx b/src/content/docs/pt-br/docs/infrastructure/enabling-validation.mdx similarity index 100% rename from src/content/docs/br/docs/infrastructure/enabling-validation.mdx rename to src/content/docs/pt-br/docs/infrastructure/enabling-validation.mdx diff --git a/src/content/docs/br/docs/infrastructure/identity.mdx b/src/content/docs/pt-br/docs/infrastructure/identity.mdx similarity index 100% rename from src/content/docs/br/docs/infrastructure/identity.mdx rename to src/content/docs/pt-br/docs/infrastructure/identity.mdx diff --git a/src/content/docs/br/docs/infrastructure/installing-xahaud.mdx b/src/content/docs/pt-br/docs/infrastructure/installing-xahaud.mdx similarity index 100% rename from src/content/docs/br/docs/infrastructure/installing-xahaud.mdx rename to src/content/docs/pt-br/docs/infrastructure/installing-xahaud.mdx diff --git a/src/content/docs/br/docs/infrastructure/interacting.mdx b/src/content/docs/pt-br/docs/infrastructure/interacting.mdx similarity index 100% rename from src/content/docs/br/docs/infrastructure/interacting.mdx rename to src/content/docs/pt-br/docs/infrastructure/interacting.mdx diff --git a/src/content/docs/br/docs/infrastructure/system-requirements.mdx b/src/content/docs/pt-br/docs/infrastructure/system-requirements.mdx similarity index 100% rename from src/content/docs/br/docs/infrastructure/system-requirements.mdx rename to src/content/docs/pt-br/docs/infrastructure/system-requirements.mdx diff --git a/src/content/docs/br/docs/infrastructure/updating-xahaud.mdx b/src/content/docs/pt-br/docs/infrastructure/updating-xahaud.mdx similarity index 100% rename from src/content/docs/br/docs/infrastructure/updating-xahaud.mdx rename to src/content/docs/pt-br/docs/infrastructure/updating-xahaud.mdx diff --git a/src/content/docs/br/docs/protocol-reference/binary-format.mdx b/src/content/docs/pt-br/docs/protocol-reference/binary-format.mdx similarity index 100% rename from src/content/docs/br/docs/protocol-reference/binary-format.mdx rename to src/content/docs/pt-br/docs/protocol-reference/binary-format.mdx diff --git a/src/content/docs/br/docs/protocol-reference/data-types/base-58-encodings.mdx b/src/content/docs/pt-br/docs/protocol-reference/data-types/base-58-encodings.mdx similarity index 100% rename from src/content/docs/br/docs/protocol-reference/data-types/base-58-encodings.mdx rename to src/content/docs/pt-br/docs/protocol-reference/data-types/base-58-encodings.mdx diff --git a/src/content/docs/br/docs/protocol-reference/data-types/currency-formats.mdx b/src/content/docs/pt-br/docs/protocol-reference/data-types/currency-formats.mdx similarity index 100% rename from src/content/docs/br/docs/protocol-reference/data-types/currency-formats.mdx rename to src/content/docs/pt-br/docs/protocol-reference/data-types/currency-formats.mdx diff --git a/src/content/docs/br/docs/protocol-reference/data-types/index.mdx b/src/content/docs/pt-br/docs/protocol-reference/data-types/index.mdx similarity index 100% rename from src/content/docs/br/docs/protocol-reference/data-types/index.mdx rename to src/content/docs/pt-br/docs/protocol-reference/data-types/index.mdx diff --git a/src/content/docs/br/docs/protocol-reference/ledger-data/index.mdx b/src/content/docs/pt-br/docs/protocol-reference/ledger-data/index.mdx similarity index 100% rename from src/content/docs/br/docs/protocol-reference/ledger-data/index.mdx rename to src/content/docs/pt-br/docs/protocol-reference/ledger-data/index.mdx diff --git a/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-header.mdx b/src/content/docs/pt-br/docs/protocol-reference/ledger-data/ledger-header.mdx similarity index 100% rename from src/content/docs/br/docs/protocol-reference/ledger-data/ledger-header.mdx rename to src/content/docs/pt-br/docs/protocol-reference/ledger-data/ledger-header.mdx diff --git a/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-object-ids.mdx b/src/content/docs/pt-br/docs/protocol-reference/ledger-data/ledger-object-ids.mdx similarity index 100% rename from src/content/docs/br/docs/protocol-reference/ledger-data/ledger-object-ids.mdx rename to src/content/docs/pt-br/docs/protocol-reference/ledger-data/ledger-object-ids.mdx diff --git a/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/accountroot.mdx b/src/content/docs/pt-br/docs/protocol-reference/ledger-data/ledger-objects-types/accountroot.mdx similarity index 100% rename from src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/accountroot.mdx rename to src/content/docs/pt-br/docs/protocol-reference/ledger-data/ledger-objects-types/accountroot.mdx diff --git a/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/amendments.mdx b/src/content/docs/pt-br/docs/protocol-reference/ledger-data/ledger-objects-types/amendments.mdx similarity index 100% rename from src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/amendments.mdx rename to src/content/docs/pt-br/docs/protocol-reference/ledger-data/ledger-objects-types/amendments.mdx diff --git a/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/check.mdx b/src/content/docs/pt-br/docs/protocol-reference/ledger-data/ledger-objects-types/check.mdx similarity index 100% rename from src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/check.mdx rename to src/content/docs/pt-br/docs/protocol-reference/ledger-data/ledger-objects-types/check.mdx diff --git a/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/cron.mdx b/src/content/docs/pt-br/docs/protocol-reference/ledger-data/ledger-objects-types/cron.mdx similarity index 100% rename from src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/cron.mdx rename to src/content/docs/pt-br/docs/protocol-reference/ledger-data/ledger-objects-types/cron.mdx diff --git a/src/content/docs/pt-br/docs/protocol-reference/ledger-data/ledger-objects-types/deposit-pre-auth.mdx b/src/content/docs/pt-br/docs/protocol-reference/ledger-data/ledger-objects-types/deposit-pre-auth.mdx new file mode 100644 index 0000000..6fcf6e5 --- /dev/null +++ b/src/content/docs/pt-br/docs/protocol-reference/ledger-data/ledger-objects-types/deposit-pre-auth.mdx @@ -0,0 +1,45 @@ +--- +title: Deposit Pre Auth +--- +[\[Fonte\]](https://github.com/ripple/rippled/blob/master/src/ripple/protocol/impl/LedgerFormats.cpp#L172-L178) + +Um objeto `DepositPreauth` rastreia uma pré-autorização de uma conta para outra. \[Transações DepositPreauth]\[] criam esses objetos. + +Isso não tem efeito no processamento de transações a menos que a conta que forneceu a pré-autorização exija Autorização de Depósito. Nesse caso, a conta que foi pré-autorizada pode enviar pagamentos e outras transações diretamente para a conta que forneceu a pré-autorização. As pré-autorizações são unidirecionais e não têm efeito sobre pagamentos na direção oposta. + +### Exemplo JSON + +```json +{ + "LedgerEntryType": "DepositPreauth", + "Account": "rsUiUMpnrgxQp24dJYZDhmV4bE3aBtQyt8", + "Authorize": "rEhxGqkqPPSxQ3P25J66ft5TwpzV14k2de", + "Flags": 0, + "OwnerNode": "0000000000000000", + "PreviousTxnID": "3E8964D5A86B3CD6B9ECB33310D4E073D64C865A5B866200AD2B7E29F8326702", + "PreviousTxnLgrSeq": 7, + "index": "4A255038CC3ADCC1A9C91509279B59908251728D0DAADB248FFE297D0F7E068C" +} +``` + +### Campos + +Um objeto `DepositPreauth` tem os seguintes campos: + +| Campo | Tipo JSON | \[Tipo Interno]\[] | Obrigatório? | Descrição | +| ------------------- | --------- | ------------------- | ------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `Account` | String | Account | Sim | A conta que concedeu a pré-autorização. (O destino dos pagamentos pré-autorizados.) | +| `Authorize` | String | Account | Sim | A conta que recebeu a pré-autorização. (O remetente dos pagamentos pré-autorizados.) | +| `Flags` | Number | UInt32 | Sim | Um mapa de bits de flags booleanos habilitados para este objeto. Atualmente, o protocolo não define flags para objetos `DepositPreauth`. O valor é sempre `0`. | +| `LedgerEntryType` | String | UInt16 | Sim | O valor `0x0070`, mapeado para a string `DepositPreauth`, indica que este é um objeto DepositPreauth. | +| `OwnerNode` | String | UInt64 | Sim | Uma dica indicando qual página do diretório do proprietário do remetente aponta para este objeto, caso o diretório consista em múltiplas páginas. **Nota:** O objeto não contém um link direto para o diretório do proprietário que o contém, pois esse valor pode ser derivado de `Account`. | +| `PreviousTxnID` | String | Hash256 | Sim | O hash identificador da transação que mais recentemente modificou este objeto. | +| `PreviousTxnLgrSeq` | Number | UInt32 | Sim | O \[índice do ledger]\[Índice de Ledger] que contém a transação que mais recentemente modificou este objeto. | + +### Formato do ID do DepositPreauth + +O ID de um objeto `DepositPreauth` é o \[SHA-512Half]\[] dos seguintes valores, concatenados em ordem: + +* A chave de espaço DepositPreauth (`0x0070`) +* O AccountID do proprietário deste objeto (o remetente da \[transação DepositPreauth]\[] que criou este objeto; ou seja, quem concedeu a pré-autorização) +* O AccountID da conta pré-autorizada (o campo `Authorized` da \[transação DepositPreauth]\[] que criou este objeto; ou seja, quem recebeu a pré-autorização) diff --git a/src/content/docs/pt-br/docs/protocol-reference/ledger-data/ledger-objects-types/directory-node.mdx b/src/content/docs/pt-br/docs/protocol-reference/ledger-data/ledger-objects-types/directory-node.mdx new file mode 100644 index 0000000..f7731a7 --- /dev/null +++ b/src/content/docs/pt-br/docs/protocol-reference/ledger-data/ledger-objects-types/directory-node.mdx @@ -0,0 +1,96 @@ +--- +title: Directory Node +--- +[\[Fonte\]](https://github.com/ripple/rippled/blob/5d2d88209f1732a0f8d592012094e345cbe3e675/src/ripple/protocol/impl/LedgerFormats.cpp#L44) + +O tipo de objeto `DirectoryNode` fornece uma lista de links para outros objetos na árvore de estado do ledger. Um único _Diretório_ conceitual assume a forma de uma lista duplamente encadeada, com um ou mais objetos DirectoryNode, cada um contendo até 32 IDs de outros objetos. O primeiro objeto é chamado de raiz do diretório, e todos os objetos, exceto o objeto raiz, podem ser adicionados ou excluídos conforme necessário. + +Existem dois tipos de Diretórios: + +* **Diretórios de proprietário** listam outros objetos pertencentes a uma conta, como objetos `RippleState` (linha de confiança) ou `Offer`. +* **Diretórios de oferta** listam as ofertas disponíveis na exchange descentralizada. Um único diretório de oferta contém todas as ofertas com a mesma taxa de câmbio para o mesmo token (código de moeda e emissor). + +### Exemplo JSON + +_Diretório de Oferta_ + +```json +{ + "ExchangeRate": "4F069BA8FF484000", + "Flags": 0, + "Indexes": [ + "AD7EAE148287EF12D213A251015F86E6D4BD34B3C4A0A1ED9A17198373F908AD" + ], + "LedgerEntryType": "DirectoryNode", + "RootIndex": "1BBEF97EDE88D40CEE2ADE6FEF121166AFE80D99EBADB01A4F069BA8FF484000", + "TakerGetsCurrency": "0000000000000000000000000000000000000000", + "TakerGetsIssuer": "0000000000000000000000000000000000000000", + "TakerPaysCurrency": "0000000000000000000000004A50590000000000", + "TakerPaysIssuer": "5BBC0F22F61D9224A110650CFE21CC0C4BE13098", + "index": "1BBEF97EDE88D40CEE2ADE6FEF121166AFE80D99EBADB01A4F069BA8FF484000" +} +``` + +_Diretório de Proprietário_ + +```json +{ + "Flags": 0, + "Indexes": [ + "AD7EAE148287EF12D213A251015F86E6D4BD34B3C4A0A1ED9A17198373F908AD", + "E83BBB58949A8303DF07172B16FB8EFBA66B9191F3836EC27A4568ED5997BAC5" + ], + "ReferenceCount": "1", + "LedgerEntryType": "DirectoryNode", + "Owner": "rpR95n1iFkTqpoy1e878f4Z1pVHVtWKMNQ", + "RootIndex": "193C591BF62482468422313F9D3274B5927CA80B4DD3707E42015DD609E39C94", + "index": "193C591BF62482468422313F9D3274B5927CA80B4DD3707E42015DD609E39C94" +} +``` + +### Campos + +| Nome | Tipo JSON | \[Tipo Interno]\[] | Obrigatório? | Descrição | +| ------------------- | --------- | ------------------- | ------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `Owner` | String | AccountID | Não | (Somente Diretórios de Proprietário) O endereço da conta que possui os objetos neste diretório. | +| `TakerGetsCurrency` | String | Hash160 | Não | (Somente Diretórios de Oferta) O código de moeda do valor `TakerGets` das ofertas neste diretório. | +| `TakerGetsIssuer` | String | Hash160 | Não | (Somente Diretórios de Oferta) O emissor do valor `TakerGets` das ofertas neste diretório. | +| `TakerPaysCurrency` | String | Hash160 | Não | (Somente Diretórios de Oferta) O código de moeda do valor `TakerPays` das ofertas neste diretório. | +| `TakerPaysIssuer` | String | Hash160 | Não | (Somente Diretórios de Oferta) O emissor do valor `TakerPays` das ofertas neste diretório. | +| `ExchangeRate` | String | UInt64 | Não | (Somente Diretórios de Oferta) **OBSOLETO**. Não utilizar. | +| `ReferenceCount` | String | UInt64 | Não | A contagem de referências no ledger reduz o custo de armazenamento e as taxas, permitindo que múltiplas instalações do mesmo Hook apontem para o mesmo objeto no ledger, removendo-o apenas quando nenhuma conta tiver o Hook instalado. | +| `Indexes` | Array | Vector256 | Sim | O conteúdo deste Diretório: um array de IDs de outros objetos. | +| `IndexNext` | Number | UInt64 | Não | Se este Diretório consistir em múltiplas páginas, este ID aponta para o próximo objeto na cadeia, voltando ao início ao chegar ao final. | +| `IndexPrevious` | Number | UInt64 | Não | Se este Diretório consistir em múltiplas páginas, este ID aponta para o objeto anterior na cadeia, voltando ao final ao chegar ao início. | +| `NFTokenID` | String | Hash256 | Não | Não utilizado | + +### Formatos do ID do Diretório + +Existem três fórmulas diferentes para criar o ID de um DirectoryNode, dependendo do que o DirectoryNode representa: + +* A primeira página (também chamada de raiz) de um Diretório de Proprietário +* A primeira página de um Diretório de Oferta +* Páginas posteriores de qualquer tipo + +**A primeira página de um Diretório de Proprietário** tem um ID que é o \[SHA-512Half]\[] dos seguintes valores, concatenados em ordem: + +* A chave de espaço Owner Directory (`0x004F`) +* O AccountID do campo `Owner`. + +**A primeira página de um Diretório de Oferta** tem um ID especial: os 192 bits superiores definem o livro de ordens, e os 64 bits restantes definem a taxa de câmbio das ofertas nesse diretório. (O ID é big-endian, portanto o livro está nos bits mais significativos, que vêm primeiro, e a qualidade está nos bits menos significativos, que vêm por último.) + +Isso fornece uma maneira de iterar por um livro de ordens das melhores para as piores ofertas. Especificamente: os primeiros 192 bits são os primeiros 192 bits do \[SHA-512Half]\[] dos seguintes valores, concatenados em ordem: + +* A chave de espaço Book Directory (`0x0042`) +* O código de moeda de 160 bits do `TakerPaysCurrency` +* O código de moeda de 160 bits do `TakerGetsCurrency` +* O AccountID do `TakerPaysIssuer` +* O AccountID do `TakerGetsIssuer` + +Os 64 bits inferiores do ID de um Diretório de Oferta representam o valor `TakerPays` dividido pelo valor `TakerGets` das ofertas naquele diretório como um número de 64 bits no formato interno de quantidade do Xahau. + +**Se o DirectoryNode não for a primeira página do Diretório** (independentemente de ser um Diretório de Proprietário ou de Oferta), então ele tem um ID que é o \[SHA-512Half]\[] dos seguintes valores, concatenados em ordem: + +* A chave de espaço DirectoryNode (`0x0064`) +* O ID do DirectoryNode raiz +* O número de página deste objeto. (Como 0 é o DirectoryNode raiz, este valor é um inteiro 1 ou maior.) diff --git a/src/content/docs/pt-br/docs/protocol-reference/ledger-data/ledger-objects-types/emitted-txn.mdx b/src/content/docs/pt-br/docs/protocol-reference/ledger-data/ledger-objects-types/emitted-txn.mdx new file mode 100644 index 0000000..adc4b23 --- /dev/null +++ b/src/content/docs/pt-br/docs/protocol-reference/ledger-data/ledger-objects-types/emitted-txn.mdx @@ -0,0 +1,61 @@ +--- +title: Emitted Txn +--- +_(Adicionado pela \[emenda Hooks]\[].)_ + +Um objeto `EmittedTxn` descreve uma transação que foi emitida por um hook. O objeto contém todos os campos da transação original, juntamente com detalhes adicionais sobre a emissão. + +### Exemplo 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" +} +``` + +### Campos + +Um objeto `EmittedTxn` tem os seguintes campos: + +| Campo | Tipo JSON | \[Tipo Interno]\[] | Obrigatório? | Descrição | +| ----------------- | --------- | ------------------- | ------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `EmitDetails` | Object | Object | Sim | Contém detalhes sobre a emissão. Inclui a geração da emissão, o ônus da emissão, o endereço de callback, o hash do hook que emitiu a transação, o nonce da emissão e o ID da transação pai. | +| `TransactionType` | String | UInt16 | Sim | O tipo da transação que foi emitida. | +| `Account` | String | Account | Sim | A conta que emitiu a transação. | +| `Fee` | String | Amount | Sim | A taxa paga pela transação. | +| `Sequence` | Number | UInt32 | Sim | O número de sequência da transação. | +| `SigningPubKey` | String | Blob | Sim | A chave pública que assina a transação. | + +O objeto `EmittedTxn` também contém todos os campos da transação original. + +### Campos do EmitDetails + +Um objeto `EmitDetails` tem os seguintes campos: + +| Campo | Tipo JSON | \[Tipo Interno]\[] | Obrigatório? | Descrição | +| ----------------- | --------- | ------------------- | ------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `EmitGeneration` | Number | UInt32 | Sim | Este campo rastreia uma cadeia de transações emitidas que, por sua vez, causam a emissão de outras transações. | +| `EmitBurden` | String | UInt64 | Sim | Este campo é uma heurística para detecção de forkbombs. As taxas são baseadas no ônus e aumentarão exponencialmente quando uma reação em cadeia for iniciada, para evitar que a rede seja sobrecarregada por transações emitidas auto-reforçantes. | +| `EmitParentTxnID` | String | Hash256 | Sim | A Execução de Hook que emitiu a transação está conectada à Transação de Origem. Portanto, este campo é sempre obrigatório para o rastreamento eficiente do comportamento. | +| `EmitNonce` | String | Hash256 | Sim | As Transações Emitidas seriam idênticas com os mesmos campos e, portanto, teriam hashes de transação idênticos se um nonce não fosse utilizado. No entanto, todos os nós da rede precisam concordar com o nonce, por isso uma API Hook especial para produzir um nonce determinístico está disponível. | +| `EmitCallback` | String | AccountID | Não | Este campo é usado pelo xahld quando precisa iniciar um callback, para que saiba em qual Hook e conta iniciar o callback. Os callbacks ocorrem quando uma transação emitida é aceita em um ledger. | +| `EmitHookHash` | String | Hash256 | Sim | O SHA512H do Hook no momento em que foi executado. | diff --git a/src/content/docs/pt-br/docs/protocol-reference/ledger-data/ledger-objects-types/escrow.mdx b/src/content/docs/pt-br/docs/protocol-reference/ledger-data/ledger-objects-types/escrow.mdx new file mode 100644 index 0000000..ec17617 --- /dev/null +++ b/src/content/docs/pt-br/docs/protocol-reference/ledger-data/ledger-objects-types/escrow.mdx @@ -0,0 +1,67 @@ +--- +title: Escrow +--- +[\[Fonte\]](https://github.com/ripple/rippled/blob/c6b6d82a754fe449cc533e18659df483c10a5c98/src/ripple/protocol/impl/LedgerFormats.cpp#L90-L101) + +_(Adicionado pela \[emenda Escrow]\[].)_ + +O tipo de objeto `Escrow` representa um pagamento retido em XAH ou IOU aguardando execução ou cancelamento. Uma \[transação EscrowCreate]\[] cria um objeto `Escrow` no ledger. Uma transação \[EscrowFinish]\[] ou \[EscrowCancel]\[] bem-sucedida exclui o objeto. + +Se o objeto `Escrow` tiver uma [_crypto-condition_](https://tools.ietf.org/html/draft-thomas-crypto-conditions-02), o pagamento só pode ser concluído se uma transação EscrowFinish fornecer o _fulfillment_ correspondente que satisfaça a condição. (O único tipo de crypto-condition suportado é o [PREIMAGE-SHA-256](https://tools.ietf.org/html/draft-thomas-crypto-conditions-02#section-8.1).) Se o objeto `Escrow` tiver um tempo `FinishAfter`, o pagamento retido só pode ser executado após esse momento. + +Um objeto `Escrow` está associado a dois endereços: + +* O proprietário, que fornece o XAH ou IOU ao criar o objeto `Escrow`. Se o pagamento retido for cancelado, o XAH ou IOU retorna ao proprietário. +* O destino, para onde o XAH ou IOU é pago quando o pagamento retido é bem-sucedido. O destino pode ser o mesmo que o proprietário. + +### Exemplo 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" +} +``` + +### Campos + +Um objeto `Escrow` tem os seguintes campos: + +| Nome | Tipo JSON | \[Tipo Interno]\[] | Obrigatório? | Descrição | +| ------------------- | ---------------- | ------------------- | ------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `Account` | String | AccountID | Sim | O endereço do proprietário (remetente) deste pagamento retido. Esta é a conta que forneceu o valor e o recupera se o pagamento retido for cancelado. | +| `Amount` | String ou Object | Amount | Sim | O valor a ser entregue pelo pagamento retido. | +| `CancelAfter` | Number | UInt32 | Não | O pagamento retido pode ser cancelado se e somente se este campo estiver presente _e_ o tempo que especifica tiver passado. Especificamente, isso é especificado como \[segundos desde a Época Ripple]\[] e "passou" se for anterior ao horário de fechamento do ledger validado anterior. | +| `Condition` | String | Blob | Não | Uma [crypto-condition PREIMAGE-SHA-256](https://tools.ietf.org/html/draft-thomas-crypto-conditions-02#section-8.1), em hexadecimal. Se presente, a \[transação EscrowFinish]\[] deve conter um fulfillment que satisfaça essa condição. | +| `Destination` | String | AccountID | Sim | O endereço de destino para onde o valor é pago se o pagamento retido for bem-sucedido. | +| `DestinationNode` | String | UInt64 | Não | Uma dica indicando qual página do diretório do proprietário do destino aponta para este objeto, caso o diretório consista em múltiplas páginas. Omitido em escrows criados antes de habilitar a \[emenda fix1523]\[]. | +| `DestinationTag` | Number | UInt32 | Não | Uma tag arbitrária para especificar melhor o destino deste pagamento retido, como um destinatário hospedado no endereço de destino. | +| `FinishAfter` | Number | UInt32 | Não | O tempo, em \[segundos desde a Época Ripple]\[], após o qual este pagamento retido pode ser finalizado. Qualquer \[transação EscrowFinish]\[] antes deste horário falha. (Especificamente, isso é comparado com o horário de fechamento do ledger validado anterior.) | +| `Flags` | Number | UInt32 | Sim | Um mapa de bits de flags booleanos habilitados para este objeto. Atualmente, o protocolo não define flags para objetos `Escrow`. O valor é sempre `0`. | +| `LedgerEntryType` | String | UInt16 | Sim | O valor `0x0075`, mapeado para a string `Escrow`, indica que este objeto é um objeto `Escrow`. | +| `OwnerNode` | String | UInt64 | Sim | Uma dica indicando qual página do diretório do proprietário aponta para este objeto, caso o diretório consista em múltiplas páginas. **Nota:** O objeto não contém um link direto para o diretório do proprietário que o contém, pois esse valor pode ser derivado de `Account`. | +| `PreviousTxnID` | String | Hash256 | Sim | O hash identificador da transação que mais recentemente modificou este objeto. | +| `PreviousTxnLgrSeq` | Number | UInt32 | Sim | O \[índice do ledger]\[Índice de Ledger] que contém a transação que mais recentemente modificou este objeto. | +| `SourceTag` | Number | UInt32 | Não | Uma tag arbitrária para especificar melhor a origem deste pagamento retido, como um destinatário hospedado no endereço do proprietário. | +| `TransferRate` | Number | UInt32 | Não | | + +### Formato do ID do Escrow + +O ID de um objeto `Escrow` é o \[SHA-512Half]\[] dos seguintes valores, concatenados em ordem: + +* A chave de espaço Escrow (`0x0075`) +* O AccountID do remetente da \[transação EscrowCreate]\[] que criou o objeto `Escrow` +* O número de Sequência da \[transação EscrowCreate]\[] que criou o objeto `Escrow`. Se a transação EscrowCreate usou um Ticket, use o valor `TicketSequence` em vez disso. diff --git a/src/content/docs/pt-br/docs/protocol-reference/ledger-data/ledger-objects-types/fee-settings.mdx b/src/content/docs/pt-br/docs/protocol-reference/ledger-data/ledger-objects-types/fee-settings.mdx new file mode 100644 index 0000000..5aaf6fd --- /dev/null +++ b/src/content/docs/pt-br/docs/protocol-reference/ledger-data/ledger-objects-types/fee-settings.mdx @@ -0,0 +1,64 @@ +--- +title: Fee Settings +--- +[\[Fonte\]](https://github.com/ripple/rippled/blob/master/src/ripple/protocol/impl/LedgerFormats.cpp#L115-L120) + +O tipo de objeto `FeeSettings` contém o custo base atual de transação e os valores de reserva conforme determinado pela votação de taxas. Cada versão de ledger contém **no máximo um** objeto `FeeSettings`. + +### Exemplo JSON + +Exemplo de objeto `FeeSettings`: + +```json +{ + "BaseFee": "000000000000000A", + "Flags": 0, + "LedgerEntryType": "FeeSettings", + "ReferenceFeeUnits": 10, + "ReserveBase": 20000000, + "ReserveIncrement": 5000000, + "XahauActivationLgrSeq": 0, + "NetworkID": 21337, + "AccountCount": 0, + "index": "4BC50C9B0D8515D3EAAE1E74B29A95804346C491EE1A95BF25E4AAB854A6A651" +} +``` + +### Campos + +O objeto `FeeSettings` tem os seguintes campos: + +| Nome | Tipo JSON | \[Tipo Interno]\[] | Obrigatório? | Descrição | +| ----------------------- | --------- | ------------------- | ------------ | -------------------------------------------------------------------------------------------------------------------------------------------------- | +| `BaseFee` | String | UInt64 | Sim | O custo de transação da "transação de referência" em drops de XAH como hexadecimal. | +| `Flags` | Number | UInt32 | Sim | Um mapa de bits de flags booleanos habilitados para este objeto. Atualmente, o protocolo não define flags para objetos `FeeSettings`. O valor é sempre `0`. | +| `LedgerEntryType` | String | UInt16 | Sim | O valor `0x0073`, mapeado para a string `FeeSettings`, indica que este objeto contém as configurações de taxa do ledger. | +| `ReferenceFeeUnits` | Number | UInt32 | Sim | O `BaseFee` traduzido em "unidades de taxa". | +| `ReserveBase` | Number | UInt32 | Sim | A reserva base para uma conta no Xahau, em drops de XAH. | +| `ReserveIncrement` | Number | UInt32 | Sim | A reserva incremental de proprietário para posse de objetos, em drops de XAH. | +| `XahauActivationLgrSeq` | Number | UInt32 | Não | O índice do ledger onde o genesis do Xahau foi ativado. | +| `AccountCount` | Number | UInt32 | Não | O número de contas criadas na rede Xahau. | +| `NetworkID` | Number | UInt32 | Não | O ID da rede. | + +**Aviso:** O formato JSON para este tipo de objeto de ledger é incomum. O `BaseFee`, `ReserveBase` e `ReserveIncrement` indicam drops de XAH, mas _**não**_ no formato usual para \[especificação de XAH]\[Quantidade de Moeda]. + +Se a _\[emenda XAHFees]\[]_ estiver habilitada, o objeto `FeeSettings` terá estes campos em vez disso: + +| Nome | Tipo JSON | \[Tipo Interno]\[] | Obrigatório? | Descrição | +| ----------------------- | --------- | ------------------- | ------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------- | +| `BaseFeeDrops` | String | Amount | Sim | O custo de transação da "transação de referência" em drops de XAH. | +| `Flags` | Number | UInt32 | Sim | Um mapa de bits de flags booleanos habilitados para este objeto. Atualmente, o protocolo não define flags para objetos `FeeSettings`. O valor é sempre `0`. | +| `LedgerEntryType` | String | UInt16 | Sim | O valor `0x0073`, mapeado para a string `FeeSettings`, indica que este objeto contém as configurações de taxa do ledger. | +| `ReserveBaseDrops` | String | Amount | Sim | A reserva base para uma conta no XAH Ledger, em drops de XAH. | +| `ReserveIncrementDrops` | String | Amount | Sim | A reserva incremental de proprietário para posse de objetos, em drops de XAH. | +| `XahauActivationLgrSeq` | Number | UInt32 | Não | O índice do ledger onde o genesis do Xahau foi ativado. | +| `AccountCount` | Number | UInt32 | Não | O número de contas criadas na rede Xahau. | +| `NetworkID` | Number | UInt32 | Não | | + +### Formato do ID do FeeSettings + +O ID do objeto `FeeSettings` é o hash apenas da chave de espaço `FeeSettings` (`0x0065`). Isso significa que o ID do objeto `FeeSettings` em um ledger é sempre: + +``` +4BC50C9B0D8515D3EAAE1E74B29A95804346C491EE1A95BF25E4AAB854A6A651 +``` diff --git a/src/content/docs/pt-br/docs/protocol-reference/ledger-data/ledger-objects-types/hook-definition.mdx b/src/content/docs/pt-br/docs/protocol-reference/ledger-data/ledger-objects-types/hook-definition.mdx new file mode 100644 index 0000000..ab37a11 --- /dev/null +++ b/src/content/docs/pt-br/docs/protocol-reference/ledger-data/ledger-objects-types/hook-definition.mdx @@ -0,0 +1,58 @@ +--- +title: Hook Definition +--- +[\[Fonte\]](https://github.com/ripple/rippled/blob/master/src/ripple/protocol/impl/LedgerFormats.cpp#L157-L170) + +_(Adicionado pela \[emenda Hooks]\[].)_ + +Um objeto `HookDefinition` descreve um hook, que é um trecho de código executado em resposta a determinadas transações. O hook pode modificar a transação, emitir novas transações ou realizar outras ações. + +### Exemplo 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" +} +``` + +### Campos + +Um objeto `HookDefinition` tem os seguintes campos: + +| Campo | Tipo JSON | \[Tipo Interno]\[] | Obrigatório? | Descrição | +| ----------------- | --------- | ------------------- | ------------ | ---------------------------------------------------------------------------------------------------------------------- | +| `HookHash` | String | Hash256 | Sim | O identificador único do hook. | +| `HookOn` | String | Hash256 | Sim | A(s) transação(ões) que acionam o hook. | +| `HookCanEmit` | String | Hash256 | Não | A(s) transação(ões) que o hook pode emitir. | +| `HookNamespace` | String | Hash256 | Sim | O namespace do hook. | +| `HookParameters` | String | Vector | Sim | Os parâmetros que o hook aceita. | +| `HookApiVersion` | Number | UInt16 | Sim | A versão da API do hook utilizada pelo hook. | +| `CreateCode` | String | VL | Sim | O código executado quando o hook é criado. | +| `HookSetTxnID` | String | Hash256 | Sim | O ID da transação que definiu o hook. | +| `ReferenceCount` | String | UInt64 | Sim | O número de referências ao hook. | +| `Fee` | String | Amount | Sim | A taxa para execução do hook. | +| `HookCallbackFee` | String | Amount | Não | A taxa para execução da função de callback do hook. | +| `LedgerEntryType` | String | UInt16 | Sim | O valor `0x0043`, mapeado para a string `HookDefinition`, indica que este objeto é um objeto HookDefinition. | + +#### Formato do ID do Hook Definition + +O ID de um objeto `HookDefinition` é o \[SHA-512Half]\[] dos seguintes valores, concatenados em ordem: + +* A chave de espaço HookDefinition (`0x0044`) +* O `HookHash` do hook diff --git a/src/content/docs/pt-br/docs/protocol-reference/ledger-data/ledger-objects-types/hook-state.mdx b/src/content/docs/pt-br/docs/protocol-reference/ledger-data/ledger-objects-types/hook-state.mdx new file mode 100644 index 0000000..c15309e --- /dev/null +++ b/src/content/docs/pt-br/docs/protocol-reference/ledger-data/ledger-objects-types/hook-state.mdx @@ -0,0 +1,42 @@ +--- +title: Hook State +--- +[\[Fonte\]](https://github.com/ripple/rippled/blob/master/src/ripple/protocol/impl/LedgerFormats.cpp#L157-L170) + +_(Adicionado pela \[emenda Hooks]\[].)_ + +Um objeto `HookState` descreve o estado de um hook, que é um trecho de código em execução no Xahau que pode interagir com transações. O objeto `HookState` armazena o estado do hook, que pode ser modificado pelo código do hook. + +### Exemplo JSON + +```json +{ + "OwnerNode": "0000000000000000", + "HookStateKey": "49647F0D748DC3FE26BDACBC57F251AADEFFF391403EC9BF87C97F67E9977FB0", + "HookStateData": "46060241FABCF692D4D934BA2A6C4427CD4279083E38C77CBE642243E43BE291", + "LedgerEntryType": "HookState", + "index": "5463C6E08862A1FAE5EDAC12D70ADB16546A1F674930521295BC082494B62924" +} +``` + +### Campos + +Um objeto `HookState` tem os seguintes campos: + +| Campo | Tipo JSON | \[Tipo Interno]\[] | Obrigatório? | Descrição | +| ----------------- | --------- | ------------------- | ------------ | ---------------------------------------------------------------------------------------------------------------------------------- | +| `OwnerNode` | String | UInt64 | Sim | Uma dica indicando qual página do diretório do proprietário aponta para este objeto, caso o diretório consista em múltiplas páginas. | +| `HookStateKey` | String | Hash256 | Sim | A chave que identifica de forma única este estado de hook. | +| `HookStateData` | String | VL | Sim | Os dados armazenados pelo hook. Pode ser qualquer dado que o código do hook decida armazenar. | +| `LedgerEntryType` | String | UInt16 | Sim | O valor `0x0043`, mapeado para a string `HookState`, indica que este objeto é um objeto HookState. | + +#### Formato do ID do HookState + +[\[Fonte\]](https://github.com/ripple/rippled/blob/master/src/ripple/protocol/impl/Indexes.cpp#L193-L200) + +O ID de um objeto `HookState` é o \[SHA-512Half]\[] dos seguintes valores, concatenados em ordem: + +* A chave de espaço HookState (`0x0076`) +* O AccountID da conta que possui o hook +* O `HookStateKey` do objeto `HookState` +* O `HookNamespace` do hook. diff --git a/src/content/docs/pt-br/docs/protocol-reference/ledger-data/ledger-objects-types/hook.mdx b/src/content/docs/pt-br/docs/protocol-reference/ledger-data/ledger-objects-types/hook.mdx new file mode 100644 index 0000000..9dc4c7e --- /dev/null +++ b/src/content/docs/pt-br/docs/protocol-reference/ledger-data/ledger-objects-types/hook.mdx @@ -0,0 +1,57 @@ +--- +title: Hook +--- +[\[Fonte\]](https://github.com/ripple/rippled/blob/master/src/ripple/protocol/impl/LedgerFormats.cpp#L157-L170) + +_(Adicionado pela \[emenda Hooks]\[].)_ + +Um objeto `Hook` descreve um contrato inteligente, que pode ser acionado por uma transação para realizar operações predefinidas. As operações são definidas pelo criador do `Hook` e podem interagir com o ledger e as transações. + +### Exemplo JSON + +```json +{ + "Account": "rUn84CUYbNjRoTQ6mSW7BVJPSVJNLb1QLo", + "OwnerNode": "0000000000000000", + "PreviousTxnID": "5463C6E08862A1FAE5EDAC12D70ADB16546A1F674930521295BC082494B62924", + "PreviousTxnLgrSeq": 6, + "Hooks": [ + { + "HookHash": "46060241FABCF692D4D934BA2A6C4427CD4279083E38C77CBE642243E43BE291", + "HookParameters": [] + } + ], + "LedgerEntryType": "Hook", + "index": "49647F0D748DC3FE26BDACBC57F251AADEFFF391403EC9BF87C97F67E9977FB0" +} +``` + +### Campos + +Um objeto `Hook` tem os seguintes campos: + +| Campo | Tipo JSON | \[Tipo Interno]\[] | Obrigatório? | Descrição | +| ------------------- | --------- | ------------------- | ------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `Account` | String | Account | Sim | A conta que criou o Hook. | +| `OwnerNode` | String | UInt64 | Sim | Uma dica indicando qual página do diretório do proprietário aponta para este objeto, caso o diretório consista em múltiplas páginas. | +| `PreviousTxnID` | String | Hash256 | Sim | O ID da transação que mais recentemente modificou este objeto. | +| `PreviousTxnLgrSeq` | Number | UInt32 | Sim | O \[índice do ledger]\[] do ledger que contém a transação que mais recentemente modificou este objeto. | +| `Hooks` | Array | Array | Sim | Um array de objetos hook. Cada objeto tem os seguintes campos: `HookHash`, `CreateCode`, `HookGrants`, `HookNamespace`, `HookParameters`, `HookOn`, `HookApiVersion`, `Flags`. | +| `LedgerEntryType` | String | UInt16 | Sim | O valor `0x0043`, mapeado para a string `Hook`, indica que este objeto é um objeto Hook. | + +### Campos do Hook + +Os seguintes campos são utilizados no objeto hook: + +| Campo | Tipo JSON | Tipo Interno | Descrição | +| ---------------- | --------- | ------------- | ----------------------------------- | +| `HookHash` | String | Hash256 | O hash do hook. | +| `HookParameters` | Array | Array | Os parâmetros do hook. | +| `Flags` | Number | UInt32 | Flags adicionais para o hook. | + +#### Formato do ID do Hook + +O ID de um objeto `Hook` é o \[SHA-512Half]\[] dos seguintes valores, concatenados em ordem: + +* A chave de espaço Hook (`0x0048`) +* O AccountID do remetente da \[transação SetHook]\[] que criou o objeto `Hook` diff --git a/src/content/docs/pt-br/docs/protocol-reference/ledger-data/ledger-objects-types/import-vl-sequence.mdx b/src/content/docs/pt-br/docs/protocol-reference/ledger-data/ledger-objects-types/import-vl-sequence.mdx new file mode 100644 index 0000000..a9737dd --- /dev/null +++ b/src/content/docs/pt-br/docs/protocol-reference/ledger-data/ledger-objects-types/import-vl-sequence.mdx @@ -0,0 +1,36 @@ +--- +title: Import VL Sequence +--- +_(Adicionado pela \[emenda Import]\[].)_ + +O `ImportVLSequence` ajuda a rastrear e validar a ordem das operações durante o processo de importação. É usado para garantir que a sequência correta de eventos ocorra e para lidar com quaisquer discrepâncias ou atualizações na dUNL no ledger de "queima". + +### Exemplo JSON + +```json +{ + "LedgerEntryType": "ImportVLSequence", + "Flags": 0, + "ImportSequence": 2023102101, + "PublicKey": "n9LigbVAi4pQc6pU2KJvQZV5wqJ8C3sVvZvBZUopchH8vqa6PEKy", + "index": "49647F0D748DC3FE26BDACBC57F251AADEFFF391403EC9BF87C97F67E9977FB0" +} +``` + +### Campos + +Um objeto `ImportVLSequence` tem os seguintes campos: + +| Campo | Tipo JSON | \[Tipo Interno]\[] | Obrigatório? | Descrição | +| ----------------- | --------- | ------------------- | ------------ | ------------------------------------------------------------------------------------------------------------------------- | +| `LedgerEntryType` | String | UInt16 | Sim | O valor `0x0049`, mapeado para a string `ImportVLSequence`, indica que este objeto é um objeto ImportVLSequence. | +| `Flags` | Number | UInt32 | Sim | Um mapa de bits de flags booleanos. Nenhum flag é definido para o tipo de objeto `ImportVLSequence`, portanto o valor é sempre `0`. | +| `ImportSequence` | Number | UInt32 | Sim | O número de sequência atual da lista dUNL no ledger de "queima". | +| `PublicKey` | String | Blob | Sim | A `PublicKey` da lista dUNL do ledger de "queima". | + +#### Formato do ID do Import VL Sequence + +O ID de um objeto `ImportVLSequence` é o \[SHA-512Half]\[] dos seguintes valores, concatenados em ordem: + +* A chave de espaço Import VL Sequence (`0x0049`) +* A Chave Pública da Lista de Validadores de Importação diff --git a/src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/index.mdx b/src/content/docs/pt-br/docs/protocol-reference/ledger-data/ledger-objects-types/index.mdx similarity index 100% rename from src/content/docs/br/docs/protocol-reference/ledger-data/ledger-objects-types/index.mdx rename to src/content/docs/pt-br/docs/protocol-reference/ledger-data/ledger-objects-types/index.mdx diff --git a/src/content/docs/pt-br/docs/protocol-reference/ledger-data/ledger-objects-types/ledger-hashes.mdx b/src/content/docs/pt-br/docs/protocol-reference/ledger-data/ledger-objects-types/ledger-hashes.mdx new file mode 100644 index 0000000..a971e1e --- /dev/null +++ b/src/content/docs/pt-br/docs/protocol-reference/ledger-data/ledger-objects-types/ledger-hashes.mdx @@ -0,0 +1,72 @@ +--- +title: Ledger Hashes +--- +[\[Fonte\]](https://github.com/ripple/rippled/blob/master/src/ripple/protocol/impl/LedgerFormats.cpp#L104-L108) + +(Não confundir com o \[tipo de dado string "ledger hash"]\[Hash], que identifica de forma única uma versão de ledger. Esta seção descreve o tipo de objeto de ledger `LedgerHashes`.) + +O tipo de objeto `LedgerHashes` contém um histórico de ledgers anteriores que levaram a esta versão de ledger, na forma de seus hashes. Objetos deste tipo de ledger são modificados automaticamente ao fechar um ledger. (Este é um dos únicos momentos em que os dados de estado de um ledger são modificados sem uma transação ou pseudo-transação.) Os objetos `LedgerHashes` existem para tornar possível pesquisar o hash de um ledger anterior usando apenas a versão atual do ledger e, no máximo, uma consulta de uma versão anterior de ledger. + +Existem dois tipos de objetos `LedgerHashes`. Ambos os tipos têm os mesmos campos. Cada versão de ledger contém: + +* Exatamente um objeto `LedgerHashes` de "histórico recente" +* Um número de objetos `LedgerHashes` de "histórico anterior" baseado no índice atual do ledger (ou seja, o tamanho do histórico do ledger). Especificamente, o Xahau adiciona um novo objeto de "histórico anterior" a cada 65536 versões de ledger. + +**Nota:** Como exceção, um novo ledger genesis não tem nenhum objeto `LedgerHashes`, pois não tem histórico de ledger. + +Exemplo de objeto `LedgerHashes` (abreviado por comprimento): + +```json +{ + "LedgerEntryType": "LedgerHashes", + "Flags": 0, + "FirstLedgerSequence": 2, + "LastLedgerSequence": 33872029, + "Hashes": [ + "D638208ADBD04CBB10DE7B645D3AB4BA31489379411A3A347151702B6401AA78", + "254D690864E418DDD9BCAC93F41B1F53B1AE693FC5FE667CE40205C322D1BE3B", + "A2B31D28905E2DEF926362822BC412B12ABF6942B73B72A32D46ED2ABB7ACCFA", + "AB4014846DF818A4B43D6B1686D0DE0644FE711577C5AB6F0B2A21CCEE280140", + "3383784E82A8BA45F4DD5EF4EE90A1B2D3B4571317DBAC37B859836ADDE644C1", + ... (até 256 hashes de ledger) ... + ], + "index": "B4979A36CDC7F3D3D5C31A4EAE2AC7D7209DDA877588B9AFC66799692AB0D66B" +} +``` + +Um objeto `LedgerHashes` tem os seguintes campos: + +| Nome | Tipo JSON | \[Tipo Interno]\[] | Obrigatório? | Descrição | +| --------------------- | ---------------- | ------------------- | ------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `FirstLedgerSequence` | Number | UInt32 | Sim | **OBSOLETO** Não utilizar. (O objeto "hashes recentes" do Xahau de produção tem o valor `2` neste campo como resultado de um software `rippled` anterior. Esse valor é propagado conforme o objeto "hashes recentes" é atualizado. Novos objetos de "histórico anterior" não têm este campo, assim como objetos "hashes recentes" em redes paralelas iniciadas com versões mais recentes do `rippled`.) | +| `Flags` | Number | UInt32 | Sim | Um mapa de bits de flags booleanos habilitados para este objeto. Atualmente, o protocolo não define flags para objetos `LedgerHashes`. O valor é sempre `0`. | +| `Hashes` | Array de Strings | Vector256 | Sim | Um array de até 256 hashes de ledger. O conteúdo depende de qual sub-tipo de objeto `LedgerHashes` este é. | +| `LastLedgerSequence` | Number | UInt32 | Sim | O \[Índice de Ledger]\[] da última entrada no array `Hashes` deste objeto. | +| `LedgerEntryType` | String | UInt16 | Sim | O valor `0x0068`, mapeado para a string `LedgerHashes`, indica que este objeto é uma lista de hashes de ledger. | + +### LedgerHashes de Histórico Recente + +Há exatamente um objeto `LedgerHashes` do sub-tipo "histórico recente" em cada ledger após o ledger genesis. Este objeto contém os hashes identificadores das 256 versões de ledger mais recentes (ou menos, se o histórico do ledger tiver menos de 256 ledgers no total) no array `Hashes`. Sempre que um novo ledger é fechado, parte do processo de fechamento envolve atualizar o objeto de "histórico recente" com o hash da versão de ledger anterior da qual esta versão é derivada (também conhecido como o _ledger pai_ desta versão). Quando há mais de 256 hashes, o mais antigo é removido. + +Usando o objeto `LedgerHashes` de "histórico recente" de um determinado ledger, é possível obter o hash de qualquer índice de ledger dentro das 256 versões de ledger anteriores à versão de ledger fornecida. + +### LedgerHashes de Histórico Anterior + +As entradas `LedgerHashes` de "histórico anterior" coletivamente contêm o hash de cada 256ª versão de ledger (também chamados de "ledgers de flag") em todo o histórico do ledger. Quando o filho de um ledger de flag fecha, o hash do ledger de flag é adicionado ao array `Hashes` do objeto `LedgerHashes` de "histórico anterior" mais recente. A cada 65536 ledgers, o `rippled` cria um novo objeto `LedgerHashes`, de forma que cada objeto de "histórico anterior" tenha os hashes de 256 ledgers de flag. + +**Nota:** O objeto `LedgerHashes` de "histórico anterior" mais antigo contém apenas 255 entradas porque o ledger genesis tem um índice de ledger de 1, não 0. + +Os objetos `LedgerHashes` de "histórico anterior" funcionam como uma [lista de saltos](https://en.wikipedia.org/wiki/Skip_list) para que seja possível obter o hash de qualquer ledger de flag histórico a partir de seu índice. A partir daí, é possível usar o objeto de "histórico recente" daquele ledger de flag para obter o hash de qualquer outro ledger. + +### Formatos de ID do LedgerHashes + +Existem dois formatos para IDs de objetos `LedgerHashes`, dependendo se o objeto é do sub-tipo "histórico recente" ou "histórico anterior". + +O objeto `LedgerHashes` de **"histórico recente"** tem um ID que é o \[SHA-512Half]\[] da chave de espaço `LedgerHashes` (`0x0073`). Em outras palavras, o "histórico recente" sempre tem o ID `B4979A36CDC7F3D3D5C31A4EAE2AC7D7209DDA877588B9AFC66799692AB0D66B`. + +Os objetos `LedgerHashes` de **"histórico anterior"** têm um ID que é o \[SHA-512Half]\[] dos seguintes valores, concatenados em ordem: + +* A chave de espaço `LedgerHashes` (`0x0073`) +* O \[Índice de Ledger]\[] de 32 bits de um ledger de flag no array `Hashes` do objeto, dividido por 65536. + + **Dica:** Dividir por 65536 mantém os 16 bits mais significativos, que são os mesmos para todos os ledgers de flag listados em um objeto de "histórico anterior", e apenas esses ledgers. É possível usar este fato para pesquisar o objeto `LedgerHashes` que contém o hash de qualquer ledger de flag. diff --git a/src/content/docs/pt-br/docs/protocol-reference/ledger-data/ledger-objects-types/negative-unl.mdx b/src/content/docs/pt-br/docs/protocol-reference/ledger-data/ledger-objects-types/negative-unl.mdx new file mode 100644 index 0000000..1819620 --- /dev/null +++ b/src/content/docs/pt-br/docs/protocol-reference/ledger-data/ledger-objects-types/negative-unl.mdx @@ -0,0 +1,53 @@ +--- +title: Negative UNL +--- +_(Adicionado pela \[emenda NegativeUNL]\[].)_ + +O tipo de objeto `NegativeUNL` contém o status atual da UNL Negativa, uma lista de validadores confiáveis que atualmente se acredita estarem offline. + +Cada versão de ledger contém **no máximo um** objeto `NegativeUNL`. Se nenhum validador estiver atualmente desabilitado ou programado para ser desabilitado, não há objeto `NegativeUNL` no ledger. + +### Exemplo JSON + +```json +{ + "DisabledValidators": [ + { + "DisabledValidator": { + "FirstLedgerSequence": 1609728, + "PublicKey": "ED6629D456285AE3613B285F65BBFF168D695BA3921F309949AFCD2CA7AFEC16FE" + } + } + ], + "Flags": 0, + "LedgerEntryType": "NegativeUNL", + "index": "2E8A59AA9D3B5B186B0B9E0F62E6C02587CA74A4D778938E957B6357D364B244" +} +``` + +Um objeto `NegativeUNL` tem os seguintes campos: + +| Nome | Tipo JSON | \[Tipo Interno]\[] | Obrigatório? | Descrição | +| --------------------- | --------- | ------------------- | ------------ | -------------------------------------------------------------------------------------------------------------------------- | +| `DisabledValidators` | Array | Array | Não | Uma lista de objetos `DisabledValidator` (veja abaixo), cada um representando um validador confiável atualmente desabilitado. | +| `Flags` | Number | UInt32 | Sim | Um mapa de bits de flags booleanos. Nenhum flag é definido para o tipo de objeto NegativeUNL, portanto o valor é sempre `0`. | +| `LedgerEntryType` | String | UInt16 | Sim | O valor `0x004E`, mapeado para a string `NegativeUNL`, indica que este objeto é a UNL Negativa. | +| `ValidatorToDisable` | String | Blob | Não | A chave pública de um validador confiável que está programado para ser desabilitado no próximo ledger de flag. | +| `ValidatorToReEnable` | String | Blob | Não | A chave pública de um validador confiável na UNL Negativa que está programado para ser reabilitado no próximo ledger de flag. | + +### Objetos DisabledValidator + +Cada objeto `DisabledValidator` representa um validador desabilitado. Em JSON, um objeto `DisabledValidator` tem um campo, `DisabledValidator`, que por sua vez contém outro objeto com os seguintes campos: + +| Nome | Tipo JSON | \[Tipo Interno]\[] | Descrição | +| --------------------- | --------- | ------------------- | ------------------------------------------------------------------------------- | +| `FirstLedgerSequence` | Number | UInt32 | O \[índice do ledger]\[] quando o validador foi adicionado à UNL Negativa. | +| `PublicKey` | String | Blob | A chave pública mestre do validador, em hexadecimal. | + +### Formato do ID do NegativeUNL + +O ID do objeto `NegativeUNL` é o hash apenas da chave de espaço `NegativeUNL` (`0x004E`). Isso significa que o ID do objeto `NegativeUNL` em um ledger é sempre: + +``` +2E8A59AA9D3B5B186B0B9E0F62E6C02587CA74A4D778938E957B6357D364B244 +``` diff --git a/src/content/docs/pt-br/docs/protocol-reference/ledger-data/ledger-objects-types/offer.mdx b/src/content/docs/pt-br/docs/protocol-reference/ledger-data/ledger-objects-types/offer.mdx new file mode 100644 index 0000000..66f4990 --- /dev/null +++ b/src/content/docs/pt-br/docs/protocol-reference/ledger-data/ledger-objects-types/offer.mdx @@ -0,0 +1,68 @@ +--- +title: Offer +--- +[\[Fonte\]](https://github.com/ripple/rippled/blob/5d2d88209f1732a0f8d592012094e345cbe3e675/src/ripple/protocol/impl/LedgerFormats.cpp#L57) + +A entrada de ledger `Offer` descreve uma Oferta para trocar moedas na exchange descentralizada do Xahau. (Em finanças, isso é mais tradicionalmente conhecido como uma _ordem_.) Uma \[transação OfferCreate]\[] cria uma entrada `Offer` no ledger somente quando a Oferta não pode ser totalmente executada imediatamente ao consumir outras Ofertas já no ledger. + +Uma Oferta pode tornar-se sem fundos por meio de outras atividades na rede enquanto permanece no ledger. Ao processar transações, a rede elimina automaticamente quaisquer Ofertas sem fundos que essas transações encontrem. (Caso contrário, Ofertas sem fundos permanecem porque _apenas_ transações podem alterar o estado do ledger.) + +### Exemplo 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" +} +``` + +### Campos + +Um objeto `Offer` tem os seguintes campos: + +| Nome | Tipo JSON | \[Tipo Interno]\[] | Obrigatório? | Descrição | +| ------------------- | ---------------- | ------------------- | ------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `Account` | String | AccountID | Sim | O endereço da conta que possui esta Oferta. | +| `BookDirectory` | String | Hash256 | Sim | O ID do Diretório de Ofertas que aponta para esta Oferta. | +| `BookNode` | String | UInt64 | Sim | Uma dica indicando qual página do diretório de ofertas aponta para este objeto, caso o diretório consista em múltiplas páginas. | +| `Expiration` | Number | UInt32 | Não | Indica o tempo após o qual esta Oferta é considerada sem fundos. Consulte \[Especificando Tempo]\[] para detalhes. | +| `Flags` | Number | UInt32 | Sim | Um mapa de bits de flags booleanos habilitados para esta oferta. | +| `LedgerEntryType` | String | UInt16 | Sim | O valor `0x006F`, mapeado para a string `Offer`, indica que este objeto descreve uma Oferta. | +| `OwnerNode` | String | UInt64 | Sim | Uma dica indicando qual página do diretório do proprietário aponta para este objeto, caso o diretório consista em múltiplas páginas. **Nota:** A oferta não contém um link direto para o diretório do proprietário que a contém, pois esse valor pode ser derivado de `Account`. | +| `PreviousTxnID` | String | Hash256 | Sim | O hash identificador da transação que mais recentemente modificou este objeto. | +| `PreviousTxnLgrSeq` | Number | UInt32 | Sim | O \[índice do ledger]\[Índice de Ledger] que contém a transação que mais recentemente modificou este objeto. | +| `Sequence` | Number | UInt32 | Sim | O valor `Sequence` da transação \[OfferCreate]\[] que criou este objeto `Offer`. Usado em combinação com o `Account` para identificar esta Oferta. | +| `TakerPays` | String ou Object | Amount | Sim | O valor restante e tipo de moeda solicitado pelo criador da Oferta. | +| `TakerGets` | String ou Object | Amount | Sim | O valor restante e tipo de moeda fornecido pelo criador da Oferta. | + +### Flags de Offer + +Existem várias opções que podem ser habilitadas ou desabilitadas quando uma \[transação OfferCreate]\[] cria um objeto de oferta. No ledger, os flags são representados como valores binários que podem ser combinados com operações bitwise-or. Os valores de bits para os flags no ledger são diferentes dos valores usados para habilitar ou desabilitar esses flags em uma transação. Os flags de ledger têm nomes que começam com **`lsf`**. + +Objetos `Offer` podem ter os seguintes valores de flag: + +
Nome do FlagValor HexValor DecimalFlag OfferCreate CorrespondenteDescrição
lsfPassive0x0001000065536tfPassiveO objeto foi colocado como uma Oferta passiva. Isso não tem efeito sobre o objeto no ledger.
lsfSell0x00020000131072tfSellO objeto foi colocado como uma Oferta de venda. Isso não tem efeito sobre o objeto no ledger (porque tfSell só importa se você obtiver uma taxa melhor do que a solicitada, o que não pode acontecer depois que o objeto entra no ledger).
+ +### Formato do ID da Offer + +O ID de um objeto `Offer` é o \[SHA-512Half]\[] dos seguintes valores, concatenados em ordem: + +* A chave de espaço Offer (`0x006F`) +* O AccountID da conta que está fazendo a Oferta +* O número de Sequência da \[transação OfferCreate]\[] que criou a Oferta. + + Se a transação OfferCreate usou um Ticket, use o valor `TicketSequence` em vez disso. diff --git a/src/content/docs/pt-br/docs/protocol-reference/ledger-data/ledger-objects-types/pay-channel.mdx b/src/content/docs/pt-br/docs/protocol-reference/ledger-data/ledger-objects-types/pay-channel.mdx new file mode 100644 index 0000000..56d526b --- /dev/null +++ b/src/content/docs/pt-br/docs/protocol-reference/ledger-data/ledger-objects-types/pay-channel.mdx @@ -0,0 +1,99 @@ +--- +title: Pay Channel +--- +[\[Fonte\]](https://github.com/ripple/rippled/blob/c0a0b79d2d483b318ce1d82e526bd53df83a4a2c/src/ripple/protocol/impl/LedgerFormats.cpp#L180-L198) + +_(Adicionado pela \[emenda PayChan]\[].)_ + +O tipo de objeto `PayChannel` representa um canal de pagamento. Os canais de pagamento permitem pagamentos pequenos e rápidos fora do ledger em XAH ou IOU que podem ser posteriormente reconciliados com o ledger de consenso. Um canal de pagamento mantém um saldo em XAH ou IOU que só pode ser pago a um endereço de destino específico até que o canal seja fechado. Qualquer XAH ou IOU não gasto é devolvido ao proprietário do canal (o endereço de origem que o criou e financiou) quando o canal fecha. + +O tipo de \[transação PaymentChannelCreate]\[] cria um objeto `PayChannel`. Os tipos \[PaymentChannelFund]\[] e \[transação PaymentChannelClaim]\[] modificam objetos `PayChannel` existentes. + +Quando um canal de pagamento expira, inicialmente permanece no ledger, pois apenas novas transações podem modificar o conteúdo do ledger. O processamento de transações fecha automaticamente um canal de pagamento quando qualquer transação o acessa após a expiração. Para fechar um canal expirado e devolver o XAH ou IOU não gasto ao proprietário, alguns endereços devem enviar uma nova transação PaymentChannelClaim ou PaymentChannelFund acessando o canal. + +Para um exemplo de uso de canais de pagamento, consulte o Tutorial de Canais de Pagamento. + +### Exemplo 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" +} +``` + +### Campos + +Um objeto `PayChannel` tem os seguintes campos: + +| Nome | Tipo JSON | \[Tipo Interno]\[] | Obrigatório? | Descrição | +| ------------------- | ---------------- | ------------------- | ------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| `Account` | String | AccountID | Sim | O endereço de origem que possui este canal de pagamento. Provém do endereço de envio da transação que criou o canal. | +| `Amount` | String ou Object | Amount | Sim | Valor total alocado para este canal. Isso inclui valores que foram pagos ao endereço de destino. É inicialmente definido pela transação que criou o canal e pode ser aumentado se o endereço de origem enviar uma transação PaymentChannelFund. | +| `Balance` | String ou Object | Amount | Sim | Valor total já pago pelo canal. A diferença entre este valor e o campo `Amount` é quanto ainda pode ser pago ao endereço de destino com transações PaymentChannelClaim. Se o canal fechar, a diferença restante é devolvida ao endereço de origem. | +| `CancelAfter` | Number | UInt32 | Não | O tempo de expiração imutável para este canal de pagamento, em \[segundos desde a Época Ripple]\[]. Este canal está expirado se este valor estiver presente e for menor que o campo `close_time` do ledger anterior. É opcionalmente definido pela transação que criou o canal e não pode ser alterado. | +| `Destination` | String | AccountID | Sim | O endereço de destino para este canal de pagamento. Enquanto o canal de pagamento estiver aberto, este é o único endereço que pode receber o valor do canal. Provém do campo `Destination` da transação que criou o canal. | +| `DestinationTag` | Number | UInt32 | Não | Uma tag arbitrária para especificar melhor o destino deste canal de pagamento, como um destinatário hospedado no endereço de destino. | +| `DestinationNode` | String | UInt64 | Não | Uma dica indicando qual página do diretório do proprietário do destino aponta para este objeto, caso o diretório consista em múltiplas páginas. Omitido em canais de pagamento criados antes de habilitar a \[emenda fixPayChanRecipientOwnerDir]\[]. | +| `Expiration` | Number | UInt32 | Não | O tempo de expiração mutável para este canal de pagamento, em \[segundos desde a Época Ripple]\[]. O canal está expirado se este valor estiver presente e for menor que o campo `close_time` do ledger anterior. Consulte Definindo Expiração do Canal para mais detalhes. | +| `Flags` | Number | UInt32 | Sim | Um mapa de bits de flags booleanos habilitados para este objeto. Atualmente, o protocolo não define flags para objetos `PayChannel`. O valor é sempre `0`. | +| `LedgerEntryType` | String | UInt16 | Sim | O valor `0x0078`, mapeado para a string `PayChannel`, indica que este objeto é um objeto de canal de pagamento. | +| `OwnerNode` | String | UInt64 | Sim | Uma dica indicando qual página do diretório do proprietário do endereço de origem aponta para este objeto, caso o diretório consista em múltiplas páginas. | +| `PreviousTxnID` | String | Hash256 | Sim | O hash identificador da transação que mais recentemente modificou este objeto. | +| `PreviousTxnLgrSeq` | Number | UInt32 | Sim | O \[índice do ledger]\[Índice de Ledger] que contém a transação que mais recentemente modificou este objeto. | +| `PublicKey` | String | Blob | Sim | Chave pública, em hexadecimal, do par de chaves que pode ser usado para assinar reivindicações contra este canal. Pode ser qualquer chave pública secp256k1 ou Ed25519 válida. É definida pela transação que criou o canal e deve corresponder à chave pública usada nas reivindicações contra o canal. O endereço de origem do canal também pode enviar valores deste canal ao destino sem reivindicações assinadas. | +| `SettleDelay` | Number | UInt32 | Sim | Número de segundos que o endereço de origem deve aguardar para fechar o canal se ainda houver algum valor nele. Valores menores significam que o endereço de destino tem menos tempo para resgatar quaisquer reivindicações pendentes após o endereço de origem solicitar o fechamento do canal. Pode ser qualquer valor que caiba em um inteiro sem sinal de 32 bits (0 a 2^32-1). É definido pela transação que cria o canal. | +| `SourceTag` | Number | UInt32 | Não | Uma tag arbitrária para especificar melhor a origem deste canal de pagamento, como um destinatário hospedado no endereço do proprietário. | +| `TransferRate` | Number | UInt32 | Não | | + +### Definindo a Expiração do Canal + +O campo `Expiration` de um canal de pagamento é o tempo de expiração mutável, em contraste com o tempo de expiração imutável representado pelo campo `CancelAfter`. A expiração de um canal é sempre considerada relativa ao campo `close_time` do ledger anterior. O campo `Expiration` é omitido quando um objeto `PayChannel` é criado. Existem várias maneiras pelas quais o campo `Expiration` de um objeto `PayChannel` pode ser atualizado, que podem ser resumidas da seguinte forma: o endereço de origem de um canal pode definir a `Expiration` do canal livremente, desde que o canal sempre permaneça aberto por pelo menos `SettleDelay` segundos após a primeira tentativa de fechamento. + +#### Endereço de Origem + +O endereço de origem pode definir a `Expiration` diretamente com o tipo de transação PaymentChannelFund. O novo valor não deve ser anterior ao menor dos seguintes valores: + +* O valor atual de `Expiration` (se definido) +* O horário de fechamento do ledger anterior mais o `SettleDelay` do canal + +Em outras palavras, o endereço de origem pode sempre tornar a `Expiration` mais tarde se uma expiração já estiver definida. A origem pode tornar um valor de `Expiration` mais cedo ou definir uma `Expiration` se uma não estiver definida atualmente, desde que o novo valor seja pelo menos `SettleDelay` segundos no futuro. Se o endereço de origem tentar definir uma data `Expiration` inválida, a transação falha com o código de erro `temBAD_EXPIRATION`. + +O endereço de origem também pode definir a `Expiration` com o flag `tfClose` do tipo de transação PaymentChannelClaim. Se o flag estiver habilitado, o ledger define automaticamente a `Expiration` para o menor dos seguintes valores: + +* O valor atual de `Expiration` (se definido) +* O horário de fechamento do ledger anterior mais o `SettleDelay` do canal + +O endereço de origem pode remover a `Expiration` com o flag `tfRenew` do tipo de transação PaymentChannelClaim. + +#### Endereço de Destino + +O endereço de destino não pode definir o campo `Expiration`. No entanto, o endereço de destino pode usar o flag `tfClose` do PaymentChannelClaim para fechar um canal imediatamente. + +#### Outros Endereços + +Se qualquer outro endereço tentar definir um campo `Expiration`, a transação falha com o código de erro `tecNO_PERMISSION`. No entanto, se o canal já estiver expirado, a transação faz com que o canal feche e resulta em `tesSUCCESS` em vez disso. + +### Formato do ID do PayChannel + +O ID de um objeto `PayChannel` é o \[SHA-512Half]\[] dos seguintes valores, concatenados em ordem: + +* A chave de espaço PayChannel (`0x0078`) +* O AccountID da conta de origem +* O AccountID da conta de destino +* O número de Sequência da \[transação PaymentChannelCreate]\[] que criou o canal. Se a transação PaymentChannelCreate usou um Ticket, use o valor `TicketSequence` em vez disso. \ No newline at end of file diff --git a/src/content/docs/pt-br/docs/protocol-reference/ledger-data/ledger-objects-types/ripple-state.mdx b/src/content/docs/pt-br/docs/protocol-reference/ledger-data/ledger-objects-types/ripple-state.mdx new file mode 100644 index 0000000..8d51def --- /dev/null +++ b/src/content/docs/pt-br/docs/protocol-reference/ledger-data/ledger-objects-types/ripple-state.mdx @@ -0,0 +1,120 @@ +--- +title: Ripple State +--- +[\[Fonte\]](https://github.com/ripple/rippled/blob/5d2d88209f1732a0f8d592012094e345cbe3e675/src/ripple/protocol/impl/LedgerFormats.cpp#L70) + +O tipo de objeto `RippleState` conecta duas contas em uma única moeda. Conceitualmente, um objeto `RippleState` representa duas linhas de confiança entre as contas, uma de cada lado. Cada conta pode alterar as configurações do seu lado do objeto `RippleState`, mas o saldo é um único valor compartilhado. Uma linha de confiança que está inteiramente em seu estado padrão é considerada igual a uma linha de confiança que não existe, portanto o `rippled` exclui objetos `RippleState` quando suas propriedades são inteiramente padrão. + +### Conta Alta vs. Conta Baixa + +Só pode haver um objeto `RippleState` por moeda para qualquer par de contas. Como nenhuma conta tem privilégios no Xahau, um objeto `RippleState` ordena os endereços de conta numericamente, para garantir uma forma canônica. O endereço que for numericamente menor quando decodificado é considerado a "conta baixa" e o outro é a "conta alta". O saldo líquido da linha de confiança é armazenado da perspectiva da conta baixa. + +O "emissor" do saldo em uma linha de confiança depende de o saldo ser positivo ou negativo. Se um objeto `RippleState` mostrar um saldo positivo, a conta alta é o emissor. Se o saldo for negativo, a conta baixa é o emissor. Frequentemente, o emissor tem seu limite definido como 0 e a outra conta tem um limite positivo, mas isso não é confiável porque os limites podem mudar sem afetar um saldo existente. + +### Exemplo 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" +} +``` + +### Campos + +Um objeto `RippleState` tem os seguintes campos: + +| Nome | Tipo JSON | Tipo Interno | Obrigatório? | Descrição | +| ------------------- | --------- | ------------- | ------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `Balance` | Object | Amount | Sim | O saldo da linha de confiança, da perspectiva da conta baixa. Um saldo negativo indica que a conta alta possui tokens emitidos pela conta baixa. O emissor aqui é sempre definido como o valor neutro ACCOUNT_ONE. | +| `Flags` | Number | UInt32 | Sim | Um mapa de bits de opções booleanas habilitadas para este objeto. | +| `HighLimit` | Object | Amount | Sim | O limite que a conta alta definiu na linha de confiança. O `issuer` é o endereço da conta alta que definiu este limite. | +| `HighNode` | String | UInt64 | Sim | (Omitido em alguns ledgers históricos) Uma dica indicando qual página do diretório do proprietário da conta alta aponta para este objeto, caso o diretório consista em múltiplas páginas. | +| `HighQualityIn` | Number | UInt32 | Não | A qualidade de entrada definida pela conta alta, como um inteiro na razão implícita `HighQualityIn`:1.000.000.000. Como caso especial, o valor 0 equivale a 1 bilhão, ou valor nominal. | +| `HighQualityOut` | Number | UInt32 | Não | A qualidade de saída definida pela conta alta, como um inteiro na razão implícita `HighQualityOut`:1.000.000.000. Como caso especial, o valor 0 equivale a 1 bilhão, ou valor nominal. | +| `LedgerEntryType` | String | UInt16 | Sim | O valor `0x0072`, mapeado para a string `RippleState`, indica que este objeto é um objeto RippleState. | +| `LowLimit` | Object | Amount | Sim | O limite que a conta baixa definiu na linha de confiança. O `issuer` é o endereço da conta baixa que definiu este limite. | +| `LowNode` | String | UInt64 | Sim | (Omitido em alguns ledgers históricos) Uma dica indicando qual página do diretório do proprietário da conta baixa aponta para este objeto, caso o diretório consista em múltiplas páginas. | +| `LowQualityIn` | Number | UInt32 | Não | A qualidade de entrada definida pela conta baixa, como um inteiro na razão implícita `LowQualityIn`:1.000.000.000. Como caso especial, o valor 0 equivale a 1 bilhão, ou valor nominal. | +| `LowQualityOut` | Number | UInt32 | Não | A qualidade de saída definida pela conta baixa, como um inteiro na razão implícita `LowQualityOut`:1.000.000.000. Como caso especial, o valor 0 equivale a 1 bilhão, ou valor nominal. | +| `PreviousTxnID` | String | Hash256 | Sim | O hash identificador da transação que mais recentemente modificou este objeto. | +| `PreviousTxnLgrSeq` | Number | UInt32 | Sim | O \[índice do ledger]\[Índice de Ledger] que contém a transação que mais recentemente modificou este objeto. | +| `LockCount` | Number | UInt32 | Não | O número total de saldos bloqueados em um objeto de ledger RippleState. | +| `LockedBalance` | Object | Amount | Não | O valor atual de tokens bloqueados para uma linha de confiança específica. | + +### Flags de RippleState + +Existem várias opções que podem ser habilitadas ou desabilitadas para uma linha de confiança. Essas opções podem ser alteradas com uma \[transação TrustSet]\[]. No ledger, os flags são representados como valores binários que podem ser combinados com operações bitwise-or. Os valores de bits para os flags no ledger são diferentes dos valores usados para habilitar ou desabilitar esses flags em uma transação. Os flags de ledger têm nomes que começam com **`lsf`**. + +Objetos RippleState podem ter os seguintes valores de flag: + +| Nome do Flag | Valor Hex | Valor Decimal | Flag TrustSet Correspondente | Descrição | +| ------------------- | ------------ | ------------- | ---------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `lsfLowReserve` | `0x00010000` | 65536 | (Nenhum) | Este objeto RippleState contribui para a reserva do proprietário da conta baixa. | +| `lsfHighReserve` | `0x00020000` | 131072 | (Nenhum) | Este objeto RippleState contribui para a reserva do proprietário da conta alta. | +| `lsfLowAuth` | `0x00040000` | 262144 | `tfSetAuth` | A conta baixa autorizou a conta alta a deter tokens emitidos pela conta baixa. | +| `lsfHighAuth` | `0x00080000` | 524288 | `tfSetAuth` | A conta alta autorizou a conta baixa a deter tokens emitidos pela conta alta. | +| `lsfLowNoRipple` | `0x00100000` | 1048576 | `tfSetNoRipple` | A conta baixa desabilitou o rippling a partir desta linha de confiança. | +| `lsfHighNoRipple` | `0x00200000` | 2097152 | `tfSetNoRipple` | A conta alta desabilitou o rippling a partir desta linha de confiança. | +| `lsfLowFreeze` | `0x00400000` | 4194304 | `tfSetFreeze` | A conta baixa congelou a linha de confiança, impedindo a conta alta de transferir o ativo. | +| `lsfHighFreeze` | `0x00800000` | 8388608 | `tfSetFreeze` | A conta alta congelou a linha de confiança, impedindo a conta baixa de transferir o ativo. | +| `lsfLowDeepFreeze` | `0x02000000` | 33554432 | `tfSetDeepFreeze` | A conta baixa aplicou deep-freeze na linha de confiança, impedindo a conta alta de enviar e receber o ativo. _(Requer a \[emenda DeepFreeze]\[])_ | +| `lsfHighDeepFreeze` | `0x04000000` | 67108864 | `tfSetDeepFreeze` | A conta alta aplicou deep-freeze na linha de confiança, impedindo a conta baixa de enviar e receber o ativo. _(Requer a \[emenda DeepFreeze]\[])_ | + +### Contribuição para a Reserva do Proprietário + +Se uma conta modificar uma linha de confiança para colocá-la em um estado não padrão, essa linha de confiança conta para a reserva do proprietário da conta. Em um objeto RippleState, os flags `lsfLowReserve` e `lsfHighReserve` indicam quais conta(s) são responsáveis pela reserva do proprietário. O servidor `rippled` define automaticamente esses flags quando modifica uma linha de confiança. + +Os valores que contam para o estado não padrão de uma linha de confiança são os seguintes: + +| A conta alta é responsável se... | A conta baixa é responsável se... | +| ------------------------------------------------------------- | ------------------------------------------------------------- | +| `Balance` é negativo (a conta alta detém moeda) | `Balance` é positivo (a conta baixa detém moeda) | +| `HighLimit` não é `0` | `LowLimit` não é `0` | +| `LowQualityIn` não é `0` e não é `1000000000` | `HighQualityIn` não é `0` e não é `1000000000` | +| `LowQualityOut` não é `0` e não é `1000000000` | `HighQualityOut` não é `0` e não é `1000000000` | +| O flag `lsfHighNoRipple` não está em seu estado padrão | O flag `lsfLowNoRipple` não está em seu estado padrão | +| O flag `lsfHighFreeze` está habilitado | O flag `lsfLowFreeze` está habilitado | + +Os flags **`lsfLowAuth`** e **`lsfHighAuth`** não contam contra o estado padrão, pois não podem ser desabilitados. + +O estado padrão dos dois flags No Ripple depende do estado do flag `lsfDefaultRipple` nos objetos AccountRoot correspondentes. Se o Default Ripple estiver desabilitado (o padrão), o estado padrão do flag `lsfNoRipple` é _habilitado_ para todas as linhas de confiança de uma conta. Se uma conta habilitar o Default Ripple, o flag `lsfNoRipple` é _desabilitado_ (rippling habilitado) para as linhas de confiança da conta por padrão. + +**Nota:** Antes da introdução do flag Default Ripple na versão 0.27.3 do `rippled` (10 de março de 2015), o estado padrão para todas as linhas de confiança era com ambos os flags No Ripple desabilitados (rippling habilitado). + +Felizmente, o `rippled` usa avaliação lazy para calcular a reserva do proprietário. Isso significa que mesmo que uma conta altere o estado padrão de todas as suas linhas de confiança alterando o flag Default Ripple, a reserva dessa conta permanece a mesma inicialmente. Se uma conta modificar uma linha de confiança, o `rippled` reavalia se essa linha de confiança individual está em seu estado padrão e se deve contribuir para a reserva do proprietário. + +### Formato do ID do RippleState + +O ID de um objeto RippleState é o \[SHA-512Half]\[] dos seguintes valores, concatenados em ordem: + +* A chave de espaço RippleState (`0x0072`) +* O AccountID da conta baixa +* O AccountID da conta alta +* O código de moeda de 160 bits da(s) linha(s) de confiança diff --git a/src/content/docs/pt-br/docs/protocol-reference/ledger-data/ledger-objects-types/signers-list.mdx b/src/content/docs/pt-br/docs/protocol-reference/ledger-data/ledger-objects-types/signers-list.mdx new file mode 100644 index 0000000..4001505 --- /dev/null +++ b/src/content/docs/pt-br/docs/protocol-reference/ledger-data/ledger-objects-types/signers-list.mdx @@ -0,0 +1,98 @@ +--- +title: Signers List +--- +[\[Fonte\]](https://github.com/ripple/rippled/blob/6d2e3da30696bd10e3bb11a5ff6d45d2c4dae90f/src/ripple/protocol/impl/LedgerFormats.cpp#L127) + +_(Adicionado pela \[emenda MultiSign]\[].)_ + +O tipo de objeto `SignerList` representa uma lista de partes que, como grupo, estão autorizadas a assinar uma transação em lugar de uma conta individual. É possível criar, substituir ou remover uma lista de assinantes usando uma \[transação SignerListSet]\[]. + +### Exemplo 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" +} +``` + +### Campos + +Um objeto `SignerList` tem os seguintes campos: + +| Nome | Tipo JSON | Tipo Interno | Obrigatório? | Descrição | +| ------------------- | --------- | ------------- | ------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `Flags` | Number | UInt32 | Sim | Um mapa de bits de flags booleanos habilitados para esta lista de assinantes. Para mais informações, consulte Flags de SignerList. | +| `LedgerEntryType` | String | UInt16 | Sim | O valor `0x0053`, mapeado para a string `SignerList`, indica que este objeto é um objeto SignerList. | +| `OwnerNode` | String | UInt64 | Sim | Uma dica indicando qual página do diretório do proprietário aponta para este objeto, caso o diretório consista em múltiplas páginas. | +| `PreviousTxnID` | String | Hash256 | Sim | O hash identificador da transação que mais recentemente modificou este objeto. | +| `PreviousTxnLgrSeq` | Number | UInt32 | Sim | O \[índice do ledger]\[Índice de Ledger] que contém a transação que mais recentemente modificou este objeto. | +| `SignerEntries` | Array | Array | Sim | Um array de objetos Signer Entry representando as partes que fazem parte desta lista de assinantes. | +| `SignerListID` | Number | UInt32 | Sim | Um ID para esta lista de assinantes. Atualmente sempre definido como `0`. Se uma emenda futura permitir múltiplas listas de assinantes para uma conta, isso pode mudar. | +| `SignerQuorum` | Number | UInt32 | Sim | Um número alvo para os pesos dos assinantes. Para produzir uma assinatura válida para o proprietário desta SignerList, os assinantes devem fornecer assinaturas válidas cujos pesos somem este valor ou mais. | + +Os `SignerEntries` podem ser qualquer combinação de endereços com e sem fundos que usem chaves secp256k1 ou ed25519. + +#### Objeto Signer Entry + +Cada membro do campo `SignerEntries` é um objeto que descreve aquele assinante na lista. Um Signer Entry tem os seguintes campos: + +| Nome | Tipo JSON | Tipo Interno | Descrição | +| --------------- | --------- | ------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `Account` | String | AccountID | Um endereço Xahau cuja assinatura contribui para a multi-assinatura. Não precisa ser um endereço com fundos no ledger. | +| `SignerWeight` | Number | UInt16 | O peso de uma assinatura deste assinante. Uma multi-assinatura só é válida se o peso total das assinaturas fornecidas atingir ou superar o valor `SignerQuorum` da lista de assinantes. | +| `WalletLocator` | String | Hash256 | _(Opcional)_ Dados hexadecimais arbitrários. Podem ser usados para identificar o assinante ou para outros fins relacionados. _(Adicionado pela \[emenda ExpandedSignerList]\[].)_ | + +Ao processar uma transação multi-assinada, o servidor consulta os valores de `Account` em relação ao ledger no momento da execução da transação. Se o endereço _não_ corresponder a um objeto AccountRoot com fundos, então apenas a chave privada mestre associada a esse endereço pode ser usada para produzir uma assinatura válida. Se a conta _existir_ no ledger, depende do estado dessa conta. Se a conta tiver uma Chave Regular configurada, a Chave Regular pode ser usada. A chave mestre da conta só pode ser usada se não estiver desabilitada. Uma multi-assinatura não pode ser usada como parte de outra multi-assinatura. + +### Flags de SignerList + +_(Adicionado pela \[emenda MultiSignReserve]\[].)_ + +Objetos SignerList podem ter o seguinte valor de flag: + +| Nome do Flag | Valor Hex | Valor Decimal | Descrição | +| ------------------ | ------------ | ------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| `lsfOneOwnerCount` | `0x00010000` | 65536 | Se este flag estiver habilitado, esta SignerList conta como um item para fins da reserva do proprietário. Caso contrário, esta lista conta como N+2 itens, onde N é o número de assinantes que contém. Este flag é habilitado automaticamente se você adicionar ou atualizar uma lista de assinantes após a \[emenda MultiSignReserve]\[] ser habilitada. | + +### Listas de Assinantes e Reservas + +Uma lista de assinantes contribui para o requisito de reserva do seu proprietário. + +A \[emenda MultiSignReserve]\[] (habilitada em 2019-04-17) fez com que cada lista de assinantes contasse como um objeto, independentemente de quantos membros ela tenha. Como resultado, a reserva do proprietário associada a uma nova lista de assinantes é de 2 XAH. + +Uma lista de assinantes criada antes da \[emenda MultiSignReserve]\[] conta como dois objetos, e cada membro da lista conta como um. Como resultado, a reserva total do proprietário associada à lista de assinantes varia de 3 a 10 vezes a reserva exigida por uma única linha de confiança (RippleState) ou objeto Offer no ledger. Para atualizar uma lista de assinantes para usar a nova reserva reduzida, atualize a lista enviando uma \[transação SignerListSet]\[]. + +### Formato do ID do SignerList + +O ID de um objeto de lista de assinantes é o SHA-512Half dos seguintes valores, concatenados em ordem: + +* A chave de espaço RippleState (`0x0053`) +* O AccountID do proprietário da lista de assinantes +* O `SignerListID` (atualmente sempre `0`) diff --git a/src/content/docs/pt-br/docs/protocol-reference/ledger-data/ledger-objects-types/ticket.mdx b/src/content/docs/pt-br/docs/protocol-reference/ledger-data/ledger-objects-types/ticket.mdx new file mode 100644 index 0000000..f26b199 --- /dev/null +++ b/src/content/docs/pt-br/docs/protocol-reference/ledger-data/ledger-objects-types/ticket.mdx @@ -0,0 +1,44 @@ +--- +title: Ticket +--- +[\[Fonte\]](https://github.com/ripple/rippled/blob/76a6956138c4ecd156c5c408f136ed3d6ab7d0c1/src/ripple/protocol/impl/LedgerFormats.cpp#L155-L164) + +_(Adicionado pela \[emenda TicketBatch]\[].)_ + +O tipo de objeto `Ticket` representa um Ticket, que rastreia um \[número de sequência]\[Número de Sequência] de conta que foi reservado para uso futuro. É possível criar novos tickets com uma \[transação TicketCreate]\[]. \[Novo em: rippled 1.7.0]\[] + +### Exemplo JSON + +```json +{ + "Account": "rEhxGqkqPPSxQ3P25J66ft5TwpzV14k2de", + "Flags": 0, + "LedgerEntryType": "Ticket", + "OwnerNode": "0000000000000000", + "PreviousTxnID": "F19AD4577212D3BEACA0F75FE1BA1644F2E854D46E8D62E9C95D18E9708CBFB1", + "PreviousTxnLgrSeq": 4, + "TicketSequence": 3 +} +``` + +### Campos + +Um objeto `Ticket` tem os seguintes campos: + +| Nome | Tipo JSON | Tipo Interno | Obrigatório? | Descrição | +| ------------------- | --------- | ------------- | ------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `Account` | String | AccountID | Sim | A conta que possui este Ticket. | +| `Flags` | Number | UInt32 | Sim | Um mapa de bits de flags booleanos habilitados para este objeto. Atualmente, o protocolo não define flags para objetos `Ticket`. O valor é sempre `0`. | +| `LedgerEntryType` | String | UInt16 | Sim | O valor `0x0054`, mapeado para a string `Ticket`, indica que este objeto é um objeto Ticket. | +| `OwnerNode` | String | UInt64 | Sim | Uma dica indicando qual página do diretório do proprietário aponta para este objeto, caso o diretório consista em múltiplas páginas. **Nota:** O objeto não contém um link direto para o diretório do proprietário que o contém, pois esse valor pode ser derivado de `Account`. | +| `PreviousTxnID` | String | Hash256 | Sim | O hash identificador da transação que mais recentemente modificou este objeto. | +| `PreviousTxnLgrSeq` | Number | UInt32 | Sim | O \[índice do ledger]\[Índice de Ledger] que contém a transação que mais recentemente modificou este objeto. | +| `TicketSequence` | Number | UInt32 | Sim | O \[Número de Sequência]\[] que este Ticket reserva. | + +### Formato do ID do Ticket + +O ID de um objeto Ticket é o SHA-512Half dos seguintes valores, concatenados em ordem: + +* A chave de espaço Ticket (`0x0054`) +* O AccountID do proprietário do Ticket +* O número `TicketSequence` do Ticket diff --git a/src/content/docs/pt-br/docs/protocol-reference/ledger-data/ledger-objects-types/unl-report.mdx b/src/content/docs/pt-br/docs/protocol-reference/ledger-data/ledger-objects-types/unl-report.mdx new file mode 100644 index 0000000..6e0285a --- /dev/null +++ b/src/content/docs/pt-br/docs/protocol-reference/ledger-data/ledger-objects-types/unl-report.mdx @@ -0,0 +1,63 @@ +--- +title: UNL Report +--- +_(Adicionado pela \[emenda Hooks]\[].)_ + +Um objeto `UNLReport` descreve um relatório da Lista de Nós Únicos (UNL), que é uma lista de nós validadores confiáveis pela rede para validar transações. + +### Exemplo JSON + +```json +{ + "LedgerEntryType": "UNLReport", + "PreviousTxnID": "5463C6E08862A1FAE5EDAC12D70ADB16546A1F674930521295BC082494B62924", + "PreviousTxnLgrSeq": 6, + "ImportVLKeys": [ + { + "PublicKey": "n9LigbVAi4pQc6pU2KJvQZV5wqJ8C3sVvZvBZUopchH8vqa6PEKy", + "Account": "rUn84CUYbNjRoTQ6mSW7BVJPSVJNLb1QLo" + } + ], + "ActiveValidators": [ + { + "PublicKey": "n9LigbVAi4pQc6pU2KJvQZV5wqJ8C3sVvZvBZUopchH8vqa6PEKy", + "Account": "rUn84CUYbNjRoTQ6mSW7BVJPSVJNLb1QLo" + } + ], + "index": "49647F0D748DC3FE26BDACBC57F251AADEFFF391403EC9BF87C97F67E9977FB0" +} +``` + +### Campos + +Um objeto `UNLReport` tem os seguintes campos: + +| Campo | Tipo JSON | \[Tipo Interno]\[] | Obrigatório? | Descrição | +| ------------------- | --------- | ------------------- | ------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------- | +| `LedgerEntryType` | String | UInt16 | Sim | O valor `0x0073`, mapeado para a string `UNLReport`, indica que este objeto é um objeto UNLReport. | +| `PreviousTxnID` | String | Hash256 | Sim | O hash identificador da transação que mais recentemente modificou este objeto. | +| `PreviousTxnLgrSeq` | Number | UInt32 | Sim | O índice do ledger que contém a transação que mais recentemente modificou este objeto. | +| `ImportVLKeys` | Array | Array | Não | Um array de objetos, cada um representando uma chave de validador que foi importada. Cada objeto tem um campo `PublicKey` e um campo `Account` opcional. | +| `ActiveValidators` | Array | Array | Não | Um array de objetos, cada um representando um validador ativo. Cada objeto tem um campo `PublicKey` e um campo `Account` opcional. | + +### Campos do ImportVLKey + +| Campo | Tipo JSON | \[Tipo Interno]\[] | Obrigatório? | Descrição | +| ----------- | --------- | ------------------- | ------------ | ------------------------------------------------------------------------------- | +| `PublicKey` | String | VL | Sim | A chave pública do validador importado. | +| `Account` | String | Account | Não | A conta associada à chave de validador importada. Este campo é opcional. | + +### Campos do ActiveValidator + +| Campo | Tipo JSON | \[Tipo Interno]\[] | Obrigatório? | Descrição | +| ----------- | --------- | ------------------- | ------------ | ------------------------------------------------------------------------- | +| `PublicKey` | String | VL | Sim | A chave pública do validador ativo. | +| `Account` | String | Account | Não | A conta associada ao validador ativo. Este campo é opcional. | + +### Formato do ID do UNLReport + +O ID do objeto `UNLReport` é o hash apenas da chave de espaço `UNLReport` (`0x0052`). Isso significa que o ID do objeto `UNLReport` em um ledger é sempre: + +``` +61E32E7A24A238F1C619D5F9DDCC41A94B33B66C0163F7EFCC8A19C9FD6F28DC +``` diff --git a/src/content/docs/pt-br/docs/protocol-reference/ledger-data/ledger-objects-types/uritoken.mdx b/src/content/docs/pt-br/docs/protocol-reference/ledger-data/ledger-objects-types/uritoken.mdx new file mode 100644 index 0000000..317700c --- /dev/null +++ b/src/content/docs/pt-br/docs/protocol-reference/ledger-data/ledger-objects-types/uritoken.mdx @@ -0,0 +1,59 @@ +--- +title: URIToken +--- +[\[Fonte\]](https://github.com/ripple/rippled/blob/master/src/ripple/protocol/impl/LedgerFormats.cpp#L157-L170) + +_(Adicionado pela \[emenda URI Token]\[].)_ + +Um objeto `URIToken` descreve um token URI, que pode ser usado para representar um identificador de recurso único no ledger. + +### Exemplo JSON + +```json +{ + "Owner": "rUn84CUYbNjRoTQ6mSW7BVJPSVJNLb1QLo", + "OwnerNode": "0000000000000000", + "Issuer": "rfkE1aSy9G8Upk4JssnwBxhEv5p4mn2KTy", + "URI": "DEADBEEF", + "Digest": "46060241FABCF692D4D934BA2A6C4427CD4279083E38C77CBE642243E43BE291", + "Amount": "100000000", + "Destination": "rUn84CUYbNjRoTQ6mSW7BVJPSVJNLb1QLo", + "PreviousTxnID": "5463C6E08862A1FAE5EDAC12D70ADB16546A1F674930521295BC082494B62924", + "PreviousTxnLgrSeq": 6, + "LedgerEntryType": "URIToken", + "index": "49647F0D748DC3FE26BDACBC57F251AADEFFF391403EC9BF87C97F67E9977FB0" +} +``` + +### Campos + +Um objeto `URIToken` tem os seguintes campos: + +| Campo | Tipo JSON | \[Tipo Interno]\[] | Obrigatório? | Descrição | +| ------------------- | ---------------- | ------------------- | ------------ | ---------------------------------------------------------------------------------------------------------------------------------- | +| `Owner` | String | Account | Sim | O proprietário do URI Token. | +| `OwnerNode` | String | UInt64 | Sim | Uma dica indicando qual página do diretório do proprietário aponta para este objeto, caso o diretório consista em múltiplas páginas. | +| `Issuer` | String | Account | Sim | O emissor do URI Token. | +| `URI` | String | VL | Sim | O URI representado por este token. | +| `Digest` | String | Hash256 | Não | Hash de 256 bits arbitrário fornecido pelo proprietário como identificador específico para este URI Token. | +| `Amount` | String ou Object | Amount | Não | O valor do URI Token. | +| `Destination` | String | Account | Não | O destinatário pretendido do URI Token. | +| `PreviousTxnID` | String | Hash256 | Sim | O hash identificador da transação que mais recentemente modificou este objeto. | +| `PreviousTxnLgrSeq` | Number | UInt32 | Sim | O índice do ledger que contém a transação que mais recentemente modificou este objeto. | +| `LedgerEntryType` | String | UInt16 | Sim | O valor `0x0073`, mapeado para a string `URIToken`, indica que este objeto é um objeto URI Token. | + +### Flags de URIToken + +Objetos `URIToken` podem ter os seguintes valores de flag: + +| Nome do Flag | Valor Hex | Valor Decimal | Flag URITokenMint Correspondente | Descrição | +| ------------- | ------------ | ------------- | -------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------- | +| `lsfBurnable` | `0x00000001` | 1 | `tfBurnable` | Permite que o emissor (ou uma entidade autorizada pelo emissor) destrua o `URIToken` cunhado. (O proprietário do `URIToken` _sempre_ pode fazer isso.) | + +### Formato do ID do URIToken + +O ID de um objeto `URIToken` é o \[SHA-512Half]\[] dos seguintes valores, concatenados em ordem: + +* A chave de espaço URI Token (`0x0055`) +* O AccountID do emissor do URI Token +* O URI representado pelo URI Token diff --git a/src/content/docs/br/docs/protocol-reference/transactions/index.mdx b/src/content/docs/pt-br/docs/protocol-reference/transactions/index.mdx similarity index 100% rename from src/content/docs/br/docs/protocol-reference/transactions/index.mdx rename to src/content/docs/pt-br/docs/protocol-reference/transactions/index.mdx diff --git a/src/content/docs/br/docs/protocol-reference/transactions/pseudo-transaction-types/cron.mdx b/src/content/docs/pt-br/docs/protocol-reference/transactions/pseudo-transaction-types/cron.mdx similarity index 100% rename from src/content/docs/br/docs/protocol-reference/transactions/pseudo-transaction-types/cron.mdx rename to src/content/docs/pt-br/docs/protocol-reference/transactions/pseudo-transaction-types/cron.mdx diff --git a/src/content/docs/br/docs/protocol-reference/transactions/pseudo-transaction-types/emitfailure.mdx b/src/content/docs/pt-br/docs/protocol-reference/transactions/pseudo-transaction-types/emitfailure.mdx similarity index 100% rename from src/content/docs/br/docs/protocol-reference/transactions/pseudo-transaction-types/emitfailure.mdx rename to src/content/docs/pt-br/docs/protocol-reference/transactions/pseudo-transaction-types/emitfailure.mdx diff --git a/src/content/docs/br/docs/protocol-reference/transactions/pseudo-transaction-types/enableamendment.mdx b/src/content/docs/pt-br/docs/protocol-reference/transactions/pseudo-transaction-types/enableamendment.mdx similarity index 100% rename from src/content/docs/br/docs/protocol-reference/transactions/pseudo-transaction-types/enableamendment.mdx rename to src/content/docs/pt-br/docs/protocol-reference/transactions/pseudo-transaction-types/enableamendment.mdx diff --git a/src/content/docs/br/docs/protocol-reference/transactions/pseudo-transaction-types/index.mdx b/src/content/docs/pt-br/docs/protocol-reference/transactions/pseudo-transaction-types/index.mdx similarity index 100% rename from src/content/docs/br/docs/protocol-reference/transactions/pseudo-transaction-types/index.mdx rename to src/content/docs/pt-br/docs/protocol-reference/transactions/pseudo-transaction-types/index.mdx diff --git a/src/content/docs/br/docs/protocol-reference/transactions/pseudo-transaction-types/setfee.mdx b/src/content/docs/pt-br/docs/protocol-reference/transactions/pseudo-transaction-types/setfee.mdx similarity index 100% rename from src/content/docs/br/docs/protocol-reference/transactions/pseudo-transaction-types/setfee.mdx rename to src/content/docs/pt-br/docs/protocol-reference/transactions/pseudo-transaction-types/setfee.mdx diff --git a/src/content/docs/br/docs/protocol-reference/transactions/pseudo-transaction-types/unlmodify.mdx b/src/content/docs/pt-br/docs/protocol-reference/transactions/pseudo-transaction-types/unlmodify.mdx similarity index 100% rename from src/content/docs/br/docs/protocol-reference/transactions/pseudo-transaction-types/unlmodify.mdx rename to src/content/docs/pt-br/docs/protocol-reference/transactions/pseudo-transaction-types/unlmodify.mdx diff --git a/src/content/docs/br/docs/protocol-reference/transactions/pseudo-transaction-types/unlreport.mdx b/src/content/docs/pt-br/docs/protocol-reference/transactions/pseudo-transaction-types/unlreport.mdx similarity index 100% rename from src/content/docs/br/docs/protocol-reference/transactions/pseudo-transaction-types/unlreport.mdx rename to src/content/docs/pt-br/docs/protocol-reference/transactions/pseudo-transaction-types/unlreport.mdx diff --git a/src/content/docs/br/docs/protocol-reference/transactions/transaction-common-fields.mdx b/src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-common-fields.mdx similarity index 100% rename from src/content/docs/br/docs/protocol-reference/transactions/transaction-common-fields.mdx rename to src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-common-fields.mdx diff --git a/src/content/docs/br/docs/protocol-reference/transactions/transaction-metadata.mdx b/src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-metadata.mdx similarity index 100% rename from src/content/docs/br/docs/protocol-reference/transactions/transaction-metadata.mdx rename to src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-metadata.mdx diff --git a/src/content/docs/br/docs/protocol-reference/transactions/transaction-results/index.mdx b/src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-results/index.mdx similarity index 100% rename from src/content/docs/br/docs/protocol-reference/transactions/transaction-results/index.mdx rename to src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-results/index.mdx diff --git a/src/content/docs/br/docs/protocol-reference/transactions/transaction-results/tec-codes.mdx b/src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-results/tec-codes.mdx similarity index 100% rename from src/content/docs/br/docs/protocol-reference/transactions/transaction-results/tec-codes.mdx rename to src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-results/tec-codes.mdx diff --git a/src/content/docs/br/docs/protocol-reference/transactions/transaction-results/tef-codes.mdx b/src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-results/tef-codes.mdx similarity index 100% rename from src/content/docs/br/docs/protocol-reference/transactions/transaction-results/tef-codes.mdx rename to src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-results/tef-codes.mdx diff --git a/src/content/docs/br/docs/protocol-reference/transactions/transaction-results/tel-codes.mdx b/src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-results/tel-codes.mdx similarity index 100% rename from src/content/docs/br/docs/protocol-reference/transactions/transaction-results/tel-codes.mdx rename to src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-results/tel-codes.mdx diff --git a/src/content/docs/br/docs/protocol-reference/transactions/transaction-results/tem-codes.mdx b/src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-results/tem-codes.mdx similarity index 100% rename from src/content/docs/br/docs/protocol-reference/transactions/transaction-results/tem-codes.mdx rename to src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-results/tem-codes.mdx diff --git a/src/content/docs/br/docs/protocol-reference/transactions/transaction-results/ter-codes.mdx b/src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-results/ter-codes.mdx similarity index 100% rename from src/content/docs/br/docs/protocol-reference/transactions/transaction-results/ter-codes.mdx rename to src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-results/ter-codes.mdx diff --git a/src/content/docs/br/docs/protocol-reference/transactions/transaction-results/tes-codes.mdx b/src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-results/tes-codes.mdx similarity index 100% rename from src/content/docs/br/docs/protocol-reference/transactions/transaction-results/tes-codes.mdx rename to src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-results/tes-codes.mdx diff --git a/src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-types/accountdelete.mdx b/src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-types/accountdelete.mdx new file mode 100644 index 0000000..2408913 --- /dev/null +++ b/src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-types/accountdelete.mdx @@ -0,0 +1,60 @@ +--- +title: AccountDelete +description: >- + Uma transação AccountDelete exclui uma conta e quaisquer objetos que ela possui no + Xahau, se possível, enviando o XAH restante da conta para uma conta de + destino especificada. +sidebar: + badge: + text: Desabilitado + variant: danger +--- +import { Aside } from '@astrojs/starlight/components'; + +\[[Fonte](https://github.com/Xahau/xahaud/blob/dev/src/ripple/app/tx/impl/DeleteAccount.cpp)] + +_Adicionado pela emenda DeletableAccounts_ + + + +### Exemplo + +```json +{ + "TransactionType": "AccountDelete", + "Account": "rWYkbWkCeg8dP6rXALnjgZSjjLyih5NXm", + "Destination": "rPT1Sjq2YGrBMTttX4GZHjKu9dyfzbpAYe", + "DestinationTag": 13, + "Fee": "2000000", + "Sequence": 2470665, + "Flags": 2147483648 +} +``` + +| Campo | Tipo JSON | \[Tipo Interno]\[] | Descrição | +| ---------------- | ---------------------- | ------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| `Destination` | String - \[Address]\[] | AccountID | O endereço de uma conta para receber qualquer XAH restante após a exclusão da conta remetente. Deve ser uma conta ativa no ledger e não pode ser a conta remetente. | +| `DestinationTag` | Number | UInt32 | _(Opcional)_ Tag de destino arbitrária que identifica um destinatário hospedado ou outras informações para o destinatário do XAH restante da conta excluída. | + +### Custo Especial de Transação + +Como medida adicional de dissuasão contra spam no ledger, a transação AccountDelete exige um custo de transação muito maior que o usual: em vez do mínimo padrão de 0,00001 XAH, o AccountDelete deve destruir pelo menos o valor da reserva do proprietário, atualmente 2 XRP. Isso desencoraja a criação excessiva de novas contas, pois o requisito de reserva não pode ser totalmente recuperado ao excluir a conta. + +O custo da transação sempre se aplica quando uma transação é incluída em um ledger validado, mesmo que a transação falhe ao excluir a conta. (Consulte Casos de Erro.) Para reduzir bastante as chances de pagar o alto custo de transação caso a conta não possa ser excluída, envie a transação com `fail_hard` habilitado. + +### Casos de Erro + +Além dos erros que podem ocorrer em todas as transações, as transações AccountDelete podem resultar nos seguintes códigos de resultado: + +| Código de Erro | Descrição | +| -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `temDISABLED` | Ocorre se a emenda DeletableAccounts não estiver habilitada. | +| `temDST_IS_SRC` | Ocorre se o `Destination` corresponder ao remetente da transação (campo `Account`). | +| `tecDST_TAG_NEEDED` | Ocorre se a conta `Destination` exigir uma tag de destino, mas o campo `DestinationTag` não tiver sido fornecido. | +| `tecNO_DST` | Ocorre se a conta `Destination` não for uma conta ativa no ledger. | +| `tecNO_PERMISSION` | Ocorre se a conta `Destination` exigir autorização de depósito e o remetente não estiver pré-autorizado. | +| `tecTOO_SOON` | Ocorre se o número de `Sequence` do remetente for muito alto. O número de `Sequence` da transação mais 256 deve ser menor que o \[Índice do Ledger]\[] atual. Isso evita a repetição de transações antigas caso esta conta seja recriada após ser excluída. | +| `tecHAS_OBLIGATIONS` | Ocorre se a conta a ser excluída estiver vinculada a objetos que não podem ser excluídos no ledger. (Isso inclui objetos criados por outras contas, como escrows e, por exemplo, NFTs cunhados, [mesmo que pertençam a outra conta](https://github.com/Xahau/xahaud/blob/dev/src/ripple/app/tx/impl/DeleteAccount.cpp#L197).) | +| `tefTOO_BIG` | Ocorre se a conta remetente estiver vinculada a mais de 1000 objetos no ledger. A transação pode ser bem-sucedida em uma nova tentativa se alguns desses objetos forem excluídos separadamente antes. | diff --git a/src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-types/accountset.mdx b/src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-types/accountset.mdx new file mode 100644 index 0000000..0f917e5 --- /dev/null +++ b/src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-types/accountset.mdx @@ -0,0 +1,116 @@ +--- +title: AccountSet +description: Uma transação AccountSet modifica as propriedades de uma conta no Xahau. +--- +\[[Fonte](https://github.com/Xahau/xahaud/blob/dev/src/ripple/app/tx/impl/SetAccount.cpp)] + +### Exemplo + +```json +{ + "TransactionType": "AccountSet", + "Account" : "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn", + "Fee": "12", + "Sequence": 5, + "Domain": "6578616D706C652E636F6D", + "SetFlag": 5, + "MessageKey": "03AB40A0490F9B7ED8DF29D246BF2D6269820A0EE7742ACDD457BEA7C7D0931EDB", + "HookStateScale": 10 +} +``` + +| Campo | Tipo JSON | \[Tipo Interno]\[] | Descrição | +| ---------------- | --------- | ------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `ClearFlag` | Number | UInt32 | _(Opcional)_ Identificador único de uma flag a ser desabilitada para esta conta. | +| `Domain` | String | Blob | _(Opcional)_ O domínio que possui esta conta, como uma string hexadecimal representando o ASCII do domínio em letras minúsculas. [Não pode ter mais de 256 bytes.](https://github.com/Xahau/xahaud/blob/55dc7a252e08a0b02cd5aa39e9b4777af3eafe77/src/ripple/app/tx/impl/SetAccount.h#L34) | +| `EmailHash` | String | Hash128 | _(Opcional)_ Um valor arbitrário de 128 bits. Convencionalmente, os clientes tratam isso como o hash md5 de um endereço de e-mail para exibir uma imagem [Gravatar](http://en.gravatar.com/site/implement/hash/). | +| `MessageKey` | String | Blob | _(Opcional)_ Chave pública para envio de mensagens criptografadas a esta conta. Para definir a chave, ela deve ter exatamente 33 bytes, com o primeiro byte indicando o tipo: `0x02` ou `0x03` para chaves secp256k1, `0xED` para chaves Ed25519. Para remover a chave, use um valor vazio. | +| `NFTokenMinter` | String | Blob | _(Opcional)_ Outra conta autorizada a cunhar NFTokens em seu nome. _(Adicionado pela emenda \[NonFungibleTokensV1_1]\[].)_ | +| `SetFlag` | Number | UInt32 | _(Opcional)_ Flag inteira a ser habilitada para esta conta. | +| `TransferRate` | Number | UInt32 | _(Opcional)_ A taxa cobrada quando usuários transferem tokens desta conta, representada em bilionésimos de uma unidade. Não pode ser maior que `2000000000` nem menor que `1000000000`, exceto pelo caso especial `0` que significa sem taxa. | +| `TickSize` | Number | UInt8 | _(Opcional)_ Tamanho do tick para ofertas envolvendo moeda emitida por este endereço. As taxas de câmbio dessas ofertas são arredondadas para este número de dígitos significativos. Valores válidos: `3` a `15` inclusive, ou `0` para desabilitar. _(Adicionado pela emenda \[TickSize]\[])_ | +| `WalletLocator` | String | Hash256 | _(Opcional)_ Um valor arbitrário de 256 bits. Se especificado, o valor é armazenado como parte da conta, mas não possui significado ou requisitos inerentes. | +| `WalletSize` | Number | UInt32 | _(Opcional)_ Não utilizado. Este campo é válido em transações AccountSet, mas não tem efeito. | +| `HookStateScale` | Number | UInt16 | _(Opcional)_ Fator de escala para determinar quando entradas de estado do Hook se tornam obsoletas. Valores válidos: `1` a `16` inclusive. _(Adicionado pela emenda [ExtendedHookState][].)_ | + +Se nenhuma dessas opções for fornecida, a transação AccountSet não tem efeito (além de destruir o custo da transação). Consulte Cancelar ou Ignorar uma Transação para mais detalhes. + +### Domínio + +O campo `Domain` é representado como a string hexadecimal do ASCII em letras minúsculas do domínio. Por exemplo, o domínio _example.com_ seria representado como `"6578616D706C652E636F6D"`. + +Para remover o campo `Domain` de uma conta, envie um AccountSet com o Domain definido como uma string vazia. + +Você pode colocar qualquer domínio no campo `Domain` da sua conta. Para provar que uma conta e um domínio pertencem à mesma pessoa ou empresa, você precisa de um "link bidirecional": + +* As contas que você possui devem ter um domínio seu no campo `Domain`. +* Nesse domínio, hospede um arquivo [xahau.toml](/docs/infrastructure/identity) listando as contas que você possui e, opcionalmente, outras informações sobre como você usa o Xahau. + +### Flags do AccountSet + +Existem várias opções que podem ser habilitadas ou desabilitadas para uma conta. As opções de conta são representadas por diferentes tipos de flags conforme a situação: + +* O tipo de transação `AccountSet` possui várias "AccountSet Flags" (prefixadas com **`asf`**) que podem habilitar uma opção quando passadas como parâmetro `SetFlag`, ou desabilitar uma opção quando passadas como parâmetro `ClearFlag`. Opções mais recentes possuem apenas esse estilo de flag. Você pode habilitar até uma flag `asf` por transação e desabilitar até uma flag `asf` por transação. +* O tipo de transação `AccountSet` possui várias flags de transação (prefixadas com **`tf`**) que podem ser usadas para habilitar ou desabilitar opções específicas de conta quando passadas no parâmetro `Flags`. Você pode habilitar e desabilitar uma combinação de configurações em uma única transação usando múltiplas flags `tf`, mas nem todas as configurações possuem flags `tf`. +* O tipo de objeto de ledger `AccountRoot` possui várias flags de estado do ledger (prefixadas com **`lsf`**) que representam o estado de opções específicas da conta em um ledger. Essas configurações se aplicam até que uma transação as altere. + +Para habilitar ou desabilitar flags de conta, use os parâmetros `SetFlag` e `ClearFlag` de uma transação AccountSet. As flags do AccountSet têm nomes que começam com **`asf`**. + +Todas as flags são desabilitadas por padrão. + +As flags do AccountSet disponíveis são: + +| Nome da Flag | Valor Decimal | Flag de Ledger Correspondente | Descrição | +| --------------------------------- | ------------- | --------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `asfAccountTxnID` | 5 | (Nenhuma) | Rastreia o ID da transação mais recente desta conta. Necessário para `AccountTxnID`. | +| `asfAllowTrustLineClawback` | 17 | `lsfAllowTrustLineClawback` | Permite que uma conta recupere tokens que emitiu. Essa flag só pode ser habilitada se o diretório de proprietário da conta estiver vazio (sem linhas de confiança, ofertas, escrows, canais de pagamento, cheques ou listas de signatários). Uma vez definida, não pode ser desfeita. | +| `asfAuthorizedNFTokenMinter` | 10 | (Nenhuma) | Habilita outra conta a cunhar tokens não fungíveis (NFTokens) em nome desta conta. Especifique a conta autorizada no campo `NFTokenMinter` do objeto AccountRoot. Para remover um cunhador autorizado, habilite esta flag e omita o campo `NFTokenMinter`. _(Adicionado pela emenda \[NonFungibleTokensV1_1]\[].)_ | +| `asfDefaultRipple` | 8 | `lsfDefaultRipple` | Habilita o rippling nas linhas de confiança desta conta por padrão. | +| `asfDepositAuth` | 9 | `lsfDepositAuth` | Habilita a Autorização de Depósito nesta conta. _(Adicionado pela emenda \[DepositAuth]\[].)_ | +| `asfDisableMaster` | 4 | `lsfDisableMaster` | Impede o uso do par de chaves mestre. Só pode ser habilitado se a conta tiver configurado outra forma de assinar transações, como uma Chave Regular ou uma Lista de Signatários. | +| `asfDisallowIncomingCheck` | 13 | `lsfDisallowIncomingCheck` | Bloqueia Cheques recebidos. _Adicionado pela emenda \[DisallowIncoming]\[]._ | +| `asfDisallowIncomingNFTokenOffer` | 12 | `lsfDisallowIncomingNFTokenOffer` | Bloqueia NFTokenOffers recebidas. _Adicionado pela emenda \[DisallowIncoming]\[]._ | +| `asfDisallowIncomingPayChan` | 14 | `lsfDisallowIncomingPayChan` | Bloqueia Canais de Pagamento recebidos. _Adicionado pela emenda \[DisallowIncoming]\[]._ | +| `asfDisallowIncomingTrustline` | 15 | `lsfDisallowIncomingTrustline` | Bloqueia linhas de confiança recebidas. _Adicionado pela emenda \[DisallowIncoming]\[]._ | +| `asfDisallowIncomingRemit` | 16 | `lsfDisallowIncomingRemit` | Bloqueia transações Remit recebidas. _Adicionado pela emenda \[Remit]\[]._ | +| `asfDisallowXRP` | 3 | `lsfDisallowXRP` | XAH não deve ser enviado para esta conta. (Aviso; não é aplicado pelo protocolo Xahau.) | +| `asfGlobalFreeze` | 7 | `lsfGlobalFreeze` | Congela todos os ativos emitidos por esta conta. | +| `asfNoFreeze` | 6 | `lsfNoFreeze` | Renuncia permanentemente à capacidade de congelar linhas de confiança individuais ou desabilitar o Congelamento Global. Esta flag nunca pode ser desabilitada após ser habilitada. | +| `asfRequireAuth` | 2 | `lsfRequireAuth` | Exige autorização para que usuários mantenham saldos emitidos por este endereço. Só pode ser habilitado se o endereço não tiver linhas de confiança conectadas a ele. | +| `asfRequireDest` | 1 | `lsfRequireDestTag` | Exige uma tag de destino para enviar transações a esta conta. | +| `asfTshCollect` | 11 | `lsfTshCollect` | O TSH paga pela execução de sua própria Cadeia de Hooks. _Adicionado pela emenda \[Hooks]\[]._ | + +Para habilitar as flags `asfDisableMaster` ou `asfNoFreeze`, você deve autorizar a transação assinando-a com o par de chaves mestre. Não é possível usar um par de chaves regular ou uma assinatura múltipla. Você pode desabilitar `asfDisableMaster` (ou seja, reabilitar o par de chaves mestre) usando um par de chaves regular ou assinatura múltipla. + +As seguintes flags de transação (`tf` flags), específicas ao tipo de transação AccountSet, servem ao mesmo propósito. Por limitação de espaço, algumas configurações não possuem flags `tf` associadas e novas flags `tf` não estão sendo adicionadas ao tipo de transação `AccountSet`. Você pode usar uma combinação de flags `tf` e `asf` para habilitar múltiplas configurações em uma única transação. + +
Nome da FlagValor HexValor DecimalSubstituída pela Flag AccountSet
tfRequireDestTag0x0001000065536asfRequireDest (SetFlag)
tfOptionalDestTag0x00020000131072asfRequireDest (ClearFlag)
tfRequireAuth0x00040000262144asfRequireAuth (SetFlag)
tfOptionalAuth0x00080000524288asfRequireAuth (ClearFlag)
tfDisallowXRP0x001000001048576asfDisallowXRP (SetFlag)
tfAllowXRP0x002000002097152asfDisallowXRP (ClearFlag)
+ +**Atenção:** Os valores numéricos das flags `tf` e `asf` nas transações não correspondem aos valores que elas definem nas contas "em repouso" no ledger. Para ler as flags de uma conta no ledger, consulte as flags do `AccountRoot`. + +#### Bloqueio de Transações Recebidas + +Transações recebidas com finalidade pouco clara podem ser um inconveniente para instituições financeiras, que precisariam reconhecer quando um cliente cometeu um erro e, potencialmente, reembolsar contas ou ajustar saldos. As flags `asfRequireDest` e `asfDisallowXRP` têm como objetivo proteger os usuários de enviar fundos acidentalmente de forma ambígua quanto ao motivo do envio. + +Por exemplo, uma tag de destino é normalmente usada para identificar qual saldo hospedado deve ser creditado quando uma instituição financeira recebe um pagamento. Se a tag de destino for omitida, pode não ser claro qual conta deve ser creditada, criando a necessidade de reembolsos, entre outros problemas. Ao usar a tag `asfRequireDest`, você garante que todo pagamento recebido tenha uma tag de destino, dificultando que outros lhe enviem um pagamento ambíguo por engano. + +Você pode se proteger contra pagamentos recebidos indesejados de moedas não-XAH simplesmente não criando linhas de confiança nessas moedas. Como o XAH não exige confiança, a flag `asfDisallowXRP` é usada para desencorajar usuários de enviar XAH para uma conta. No entanto, essa flag não é aplicada pelo protocolo Xahau, pois poderia tornar contas inutilizáveis caso fiquem sem XAH. Em vez disso, as aplicações clientes devem bloquear ou desencorajar pagamentos em XAH para contas com a flag `asfDisallowXRP` habilitada. + +Se você quiser bloquear _todos_ os pagamentos recebidos, pode habilitar a Autorização de Depósito. Isso impede que qualquer transação envie dinheiro para você, inclusive XAH, a menos que sua conta esteja abaixo do requisito de reserva. + +Se a emenda \[DisallowIncoming]\[] :not_enabled: estiver habilitada, você também terá a opção de bloquear todos os Cheques, NFTokenOffers, Canais de Pagamento e linhas de confiança recebidos. Geralmente é inofensivo receber esses objetos, mas eles podem impedir que você exclua sua conta e pode ser confuso ter objetos inesperados misturados à lista de objetos que você criou. Para bloquear objetos recebidos, use uma ou mais das seguintes flags de conta: + +* `asfDisallowIncomingCheck` - para objetos Check +* `asfDisallowIncomingNFTOffer` - para objetos NFTokenOffer +* `asfDisallowIncomingPayChan` - para objetos PayChannel +* `asfDisallowIncomingTrustline` - para objetos RippleState (linha de confiança) + +Quando uma transação criaria uma dessas entradas no ledger, se a conta de destino tiver a flag correspondente habilitada, a transação falhará com o código de resultado `tecNO_PERMISSION`. Ao contrário da Autorização de Depósito, essas configurações não impedem que você receba pagamentos em geral. Além disso, habilitar essa configuração não impede que você crie esses tipos de objetos (a menos que o destino da sua transação também esteja usando a configuração, é claro). + +### TransferRate + +O campo `TransferRate` especifica uma taxa a ser cobrada sempre que contrapartes transferem a moeda que você emite. + +Nas APIs HTTP e WebSocket, a taxa de transferência é representada como um inteiro — o valor que deve ser enviado para que 1 bilhão de unidades chegue ao destino. Por exemplo, uma taxa de transferência de 20% é representada pelo valor `1200000000`. O valor não pode ser menor que 1000000000. (Um valor menor indicaria que você está dando dinheiro para quem faz transações, o que é explorável.) Você pode especificar `0` como atalho para `1000000000`, ou seja, sem taxa. + +Consulte Taxas de Transferência para mais informações. diff --git a/src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-types/checkcancel.mdx b/src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-types/checkcancel.mdx new file mode 100644 index 0000000..fe8e09d --- /dev/null +++ b/src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-types/checkcancel.mdx @@ -0,0 +1,30 @@ +--- +title: CheckCancel +description: >- + Cancela um Check não resgatado, removendo-o do ledger sem enviar nenhum + valor. A origem ou o destino do check pode cancelar um Check a qualquer + momento usando este tipo de transação. +--- +\[[Source](https://github.com/Xahau/xahaud/blob/dev/src/ripple/app/tx/impl/URIToken.cpp)] + +_(Adicionado pela \[emenda Checks]\[].)_ + +### Exemplo + +```json +{ + "Account": "rUn84CUYbNjRoTQ6mSW7BVJPSVJNLb1QLo", + "TransactionType": "CheckCancel", + "CheckID": "49647F0D748DC3FE26BDACBC57F251AADEFFF391403EC9BF87C97F67E9977FB0", + "Fee": "12" +} +``` + +| Campo | Tipo JSON | \[Tipo Interno]\[] | Descrição | +| --------- | --------- | ------------------- | ------------------------------------------------------------------------------------------- | +| `CheckID` | String | Hash256 | O ID do objeto Check no ledger a ser cancelado, como uma string hexadecimal de 64 caracteres. | + +### Casos de Erro + +* Se o objeto identificado pelo `CheckID` não existir ou não for um Check, a transação falha com o resultado `tecNO_ENTRY`. +* Se o Check não estiver expirado e o remetente da transação CheckCancel não for a origem nem o destino do Check, a transação falha com o resultado `tecNO_PERMISSION`. diff --git a/src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-types/checkcash.mdx b/src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-types/checkcash.mdx new file mode 100644 index 0000000..615466b --- /dev/null +++ b/src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-types/checkcash.mdx @@ -0,0 +1,38 @@ +--- +title: CheckCash +description: >- + Tenta resgatar um objeto Check no ledger para receber até o valor + autorizado pela transação CheckCreate correspondente. +--- +\[[Source](https://github.com/Xahau/xahaud/blob/dev/src/ripple/app/tx/impl/URIToken.cpp)] + +_(Adicionado pela \[emenda Checks]\[].)_ + +### Exemplo + +```json +{ + "Account": "rfkE1aSy9G8Upk4JssnwBxhEv5p4mn2KTy", + "TransactionType": "CheckCash", + "Amount": "100000000", + "CheckID": "838766BA2B995C00744175F69A1B11E32C3DBC40E64801A4056FCBD657F57334", + "Fee": "12" +} +``` + +| Campo | Tipo JSON | \[Tipo Interno]\[] | Descrição | +| ------------ | ---------------------------------------------------------------------------------------------------------------------------------- | ------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `CheckID` | String | Hash256 | O ID do objeto Check no ledger a ser resgatado, como uma string hexadecimal de 64 caracteres. | +| `Amount` | [Valor de Moeda](/docs/protocol-reference/data-types/currency-formats/#specifying-currency-amounts) | Amount | _(Opcional)_ Resgata o Check por exatamente este valor, se possível. A moeda deve corresponder à do campo `SendMax` da transação CheckCreate correspondente. Você deve fornecer este campo ou `DeliverMin`. | +| `DeliverMin` | \[Valor de Moeda]\[] | Amount | _(Opcional)_ Resgata o Check por pelo menos este valor e pelo máximo possível. A moeda deve corresponder à do campo `SendMax` da transação CheckCreate correspondente. Você deve fornecer este campo ou `Amount`. | + +A transação _**deve**_ incluir `Amount` ou `DeliverMin`, mas não ambos. + +### Casos de Erro + +* Se o remetente da transação CheckCash não for o `Destination` do cheque, a transação falha com o código de resultado `tecNO_PERMISSION`. +* Se o Check identificado pelo campo `CheckID` não existir, a transação falha com o resultado `tecNO_ENTRY`. +* Se o Check identificado pelo campo `CheckID` já tiver expirado, a transação falha com o resultado `tecEXPIRED`. +* Se o destinatário do Check tiver a flag `RequireDest` habilitada, mas o Check, conforme criado, não possuir uma tag de destino, a transação falha com o código de resultado `tecDST_TAG_NEEDED`. +* Se a transação especificar ambos `Amount` e `DeliverMin`, ou omitir ambos, a transação falha com o resultado `temMALFORMED`. +* Se `Amount` ou `DeliverMin` não corresponder à moeda (e emissor, se não for XAH) do Check, a transação falha com o resultado `temBAD_CURRENCY`. diff --git a/src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-types/checkcreate.mdx b/src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-types/checkcreate.mdx new file mode 100644 index 0000000..a12bb3a --- /dev/null +++ b/src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-types/checkcreate.mdx @@ -0,0 +1,44 @@ +--- +title: CheckCreate +description: >- + Cria um objeto Check no ledger, que é um pagamento diferido que pode ser + resgatado pelo destinatário pretendido. O remetente desta transação é o + emissor do Check. +--- +\[[Source](https://github.com/Xahau/xahaud/blob/dev/src/ripple/app/tx/impl/URIToken.cpp)] + +_(Adicionado pela \[emenda Checks]\[].)_ + +### Exemplo + +```json +{ + "TransactionType": "CheckCreate", + "Account": "rUn84CUYbNjRoTQ6mSW7BVJPSVJNLb1QLo", + "Destination": "rfkE1aSy9G8Upk4JssnwBxhEv5p4mn2KTy", + "SendMax": "100000000", + "Expiration": 570113521, + "InvoiceID": "6F1DFD1D0FE8A32E40E1F2C05CF1C15545BAB56B617F9C6C2D63A6B704BEF59B", + "DestinationTag": 1, + "Fee": "12" +} +``` + +| Campo | Tipo JSON | \[Tipo Interno]\[] | Descrição | +| ---------------- | ---------------------------------------------------------------------------------------------------------------------------------- | ------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `Destination` | String | AccountID | O endereço único da conta que pode resgatar o Check. | +| `SendMax` | [Valor de Moeda](/docs/protocol-reference/data-types/currency-formats/#specifying-currency-amounts) | Amount | Valor máximo da moeda de origem que o Check pode debitar do remetente, incluindo taxas de transferência em moedas que não sejam XAH. O Check só pode creditar o destino com a mesma moeda (do mesmo emissor, para moedas que não sejam XAH). Para valores que não sejam XAH, os nomes dos campos aninhados DEVEM estar em minúsculas. | +| `DestinationTag` | Number | UInt32 | _(Opcional)_ Tag arbitrária que identifica o motivo do Check ou um destinatário hospedado a pagar. | +| `Expiration` | Number | UInt32 | _(Opcional)_ Momento após o qual o Check não é mais válido, em \[segundos desde o Epoch da Ripple]\[]. | +| `InvoiceID` | String | Hash256 | _(Opcional)_ Hash arbitrário de 256 bits representando um motivo ou identificador específico para este Check. | + +### Casos de Erro + +* Se a conta `Destination` estiver bloqueando Checks recebidos, a transação falha com o código de resultado `tecNO_PERMISSION`. +* Se o `Destination` for o remetente da transação, a transação falha com o código de resultado `temREDUNDANT`. +* Se a conta `Destination` não existir no ledger, a transação falha com o código de resultado `tecNO_DST`. +* Se a conta `Destination` tiver a flag `RequireDest` habilitada, mas a transação não incluir o campo `DestinationTag`, a transação falha com o código de resultado `tecDST_TAG_NEEDED`. +* Se `SendMax` especificar um token que esteja congelado, a transação falha com o resultado `tecFROZEN`. +* Se o `Expiration` da transação estiver no passado, a transação falha com o resultado `tecEXPIRED`. +* Se o remetente não tiver XAH suficiente para atender à reserva do proprietário após adicionar o Check, a transação falha com o resultado `tecINSUFFICIENT_RESERVE`. +* Se o remetente ou o destinatário do Check não puder possuir mais objetos no ledger, a transação falha com o resultado `tecDIR_FULL`. diff --git a/src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-types/claimreward.mdx b/src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-types/claimreward.mdx new file mode 100644 index 0000000..460f0ae --- /dev/null +++ b/src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-types/claimreward.mdx @@ -0,0 +1,63 @@ +--- +title: ClaimReward +description: >- + Uma transação ClaimReward permite que uma conta reivindique as recompensas + acumuladas. As recompensas podem ser reivindicadas pelo proprietário da conta + ou por um emissor especificado. A conta também pode cancelar a participação + nas recompensas. +--- +\[[Source](https://github.com/Xahau/xahaud/blob/dev/src/ripple/app/tx/impl/ClaimReward.cpp)] + +_(Adicionado pela \[emenda BalanceRewards]\[].)_ + +### Opt-in + Reivindicação + +```json +{ + "TransactionType": "ClaimReward", + "Account": "rWYkbWkCeg8dP6rXALnjgZSjjLyih5NXm", + "Issuer": "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh" +} +``` + +### Opt-out + +```json +{ + "TransactionType": "ClaimReward", + "Account": "rWYkbWkCeg8dP6rXALnjgZSjjLyih5NXm", + "Flags": 1 +} +``` + +### Campos + +| Campo | Tipo JSON | \[Tipo Interno]\[] | Descrição | +| --------- | --------- | ------------------- | ----------------------------------------------------------------- | +| `Account` | String | AccountID | O endereço da conta que está reivindicando a recompensa. | +| `Flags` | Number | UInt32 | _(Opcional)_ Pode ter a flag 1 definida para cancelar recompensas. | +| `Issuer` | String | AccountID | _(Opcional)_ A conta genesis. | + +### Flags do ClaimReward + +Transações do tipo ClaimReward suportam valores adicionais no campo `Flags`, conforme abaixo: + +| Nome da Flag | Valor Hex | Valor Decimal | Descrição | +| ------------ | ------------ | ------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `tfOptOut` | `0x00000001` | 1 | A flag `isOptOut` no código do ClaimReward é usada para cancelar a participação de uma conta nas recompensas, removendo os campos relacionados a recompensas do objeto da conta no ledger se o campo `sfFlags` na transação estiver definido como 1. | + +### Custo Especial de Transação + +A transação ClaimReward possui um custo de transação padrão, que é o custo mínimo exigido para todas as transações. + +### Casos de Erro + +Além dos erros que podem ocorrer em todas as transações, as transações ClaimReward podem resultar nos seguintes códigos de resultado: + +| Código de Erro | Descrição | +| ----------------- | -------------------------------------------------------------------------------------------------------------------- | +| `temDISABLED` | Ocorre se a funcionalidade não estiver habilitada. | +| `temINVALID_FLAG` | Ocorre se a flag estiver definida com um valor diferente de 1. | +| `temMALFORMED` | Ocorre se o emissor for igual à conta de origem ou se a flag e o emissor não estiverem configurados corretamente. | +| `tecNO_ISSUER` | Ocorre se o emissor não existir. | +| `terNO_ACCOUNT` | Ocorre se a conta remetente não existir. | diff --git a/src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-types/clawback.mdx b/src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-types/clawback.mdx new file mode 100644 index 0000000..d80740b --- /dev/null +++ b/src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-types/clawback.mdx @@ -0,0 +1,52 @@ +--- +title: Clawback +description: >- + Revogue tokens que foram previamente emitidos pela sua conta. +--- +\[[Source](https://github.com/Xahau/xahaud/blob/dev/src/ripple/app/tx/impl/Clawback.cpp)] + +_(Adicionado pela \[emenda Clawback]\[].)_ + +Revogue tokens que foram previamente emitidos pela sua conta. O recurso **Clawback** está desativado por padrão. Para utilizá-lo, você deve primeiro enviar uma transação **AccountSet** que habilite *Allow Trust Line Clawback*. Se sua conta já emitiu tokens, não é possível habilitar o Clawback posteriormente. Você só pode ativar *Allow Trust Line Clawback* se o seu diretório de proprietário estiver completamente vazio — ou seja, antes de criar linhas de confiança, ofertas, escrows, canais de pagamento, cheques ou listas de signatários. Uma vez habilitado, o Clawback torna-se uma capacidade permanente da sua conta e não pode ser desfeito. + +--- + +## Exemplo + +```json +{ + "TransactionType": "Clawback", + "Account": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn", + "Amount": { + "currency": "USD", + "issuer": "rfkE1aSy9G8Upk4JssnwBxhEv5p4mn2KTy", + "value": "123.45" + } +} +```` + +--- + +### Campos + +Uma transação **Clawback** inclui: + +| Campo | Tipo JSON | Descrição | +| -------- | ----------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `Amount` | *Currency Amount* | A quantidade a ser revogada, bem como a contraparte da qual ela é retirada. O `value` não pode ser zero. Se for maior que o saldo do detentor, o saldo inteiro é revogado. No subcampo `issuer`, especifique o endereço do detentor (não o do emissor). | + +No Xahau, um token IOU/Non-XAH em uma linha de confiança sempre tem um emissor, mas as linhas de confiança são bidirecionais e, em determinadas configurações, ambos os lados podem atuar como emissores. Nesta transação, o endereço do emissor vai no campo `Account`, enquanto o endereço do detentor vai no subcampo `issuer` de `Amount`. + +--- + +## Casos de Erro + +Além dos erros padrão de transação, o Clawback pode falhar com: + +| Código de Erro | Descrição | +| ------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `temDISABLED` | A emenda **Clawback** não está habilitada no Xahau. | +| `temBAD_AMOUNT` | O saldo do detentor é zero. (Não é um erro se o valor especificado exceder o saldo do detentor — nesse caso, o saldo total disponível é revogado). Também ocorre se a contraparte em `Amount` for a mesma conta que está enviando a transação. | +| `tecNO_LINE` | Não existe linha de confiança com a contraparte especificada, ou a linha de confiança tem saldo zero. | +| `tecNO_PERMISSION` | Ocorre se você tentar habilitar `lsfAllowTrustLineClawback` enquanto `lsfNoFreeze` já está habilitado, ou vice-versa. | + diff --git a/src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-types/cronset.mdx b/src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-types/cronset.mdx new file mode 100644 index 0000000..b955650 --- /dev/null +++ b/src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-types/cronset.mdx @@ -0,0 +1,101 @@ +--- +title: CronSet +description: >- + Uma transação CronSet permite que Hooks agendem auto-invocações recorrentes em + intervalos regulares, similar a cronjobs do Linux. Isso facilita estruturas + complexas de governança e processos automatizados dentro de frameworks de Hook. +--- +\[[Source](https://github.com/Xahau/xahaud/blob/dev/src/ripple/app/tx/impl/CronSet.cpp)] + +_(Adicionado pela emenda CronSet.)_ + +### Exemplo + +```json +{ + "TransactionType": "CronSet", + "Account": "rYourAccountAddress", + "StartTime": 816348759, + "RepeatCount": 3, + "DelaySeconds": 120 +} +``` + +| Campo | Tipo JSON | \[Tipo Interno]\[] | Descrição | +| -------------- | --------- | ------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `Account` | String | AccountID | A conta Hook que inicia o cron. Esta é a conta que será invocada quando o cron executar. | +| `StartTime` | Number | UInt32 | _(Opcional)_ Timestamp no formato Ripple Epoch indicando quando a primeira execução deve ocorrer. Use `0` para execução imediata. Se omitido ao excluir um cron, a transação o remove. | +| `RepeatCount` | Number | UInt32 | _(Opcional)_ Número de vezes que o cron deve executar (máximo de 256 por transação). Pode ser estendido via transações CronSet subsequentes. Omitir ao excluir um cron. | +| `DelaySeconds` | Number | UInt32 | _(Opcional)_ Intervalo de tempo em segundos entre cada execução. Omitir ao excluir um cron. | + +### Como o CronSet Funciona + +Transações CronSet habilitam a execução agendada e automatizada de Hooks na blockchain Xahau em intervalos regulares, eliminando a necessidade de serviços externos ou acionamentos manuais. + +O fluxo de trabalho envolve quatro etapas principais: + +1. Instalar um Hook com a flag `hsfCOLLECT` habilitada +2. Habilitar a Coleta de Hook por Assinatura de Transação `asfTshCollect` na sua conta (SetFlag: 11) +3. Criar uma transação CronSet com os parâmetros de agendamento +4. Deixar o Xahau gerenciar a execução automática + +### Mecanismo de Execução + +Quando um cron está pronto para executar, o motor Cron insere uma pseudo-transação do tipo `Cron` no ledger, contendo um campo `Owner` referenciando a conta Hook de origem. Desenvolvedores de Hook devem habilitar chamadas de coleta, pois o Owner constitui uma parte interessada transacional fraca. + +O Hook agendado será invocado automaticamente nos intervalos especificados sem exigir acionamentos externos. + +### Formato de Tempo + +O Xahau utiliza o tempo no formato Ripple Epoch (segundos desde 1º de janeiro de 2000), não o tempo Unix. Para converter a partir de um objeto Date do JavaScript: + +```javascript +const rippleEpochTime = Math.floor(Date.now() / 1000) - 946684800; +``` + +### Excluindo um Cron + +Para remover um Cron existente, omita `StartTime`, `RepeatCount` e `DelaySeconds` enquanto define `Flags: 1` (tfCronUnset): + +```json +{ + "TransactionType": "CronSet", + "Account": "rYourAccountAddress", + "Flags": 1 +} +``` + +### Estendendo o RepeatCount + +Ao atingir um limite mínimo, uma transação CronSet subsequente pode estender o contador de repetições além do limite inicial de 256 execuções, enviando uma nova transação CronSet com um `RepeatCount` atualizado. + +### Flags do CronSet + +Transações do tipo CronSet suportam valores adicionais no campo `Flags`, conforme abaixo: + +| Nome da Flag | Valor Hex | Valor Decimal | Descrição | +| ------------- | ------------ | ------------- | ----------------------------------------------------------------------------------- | +| `tfCronUnset` | `0x00000001` | 1 | Remove um Cron existente. Todos os campos de agendamento devem ser omitidos ao usar esta flag. | + +### Limitações e Restrições + +- CronSet não pode ser delegado a outra conta atualmente +- Hooks devem auto-emitir transações CronSet ou operar sob arranjos de gerenciamento conjunto +- `RepeatCount`: Deve ser maior que 0 e não pode exceder 256 por transação (extensível via transações subsequentes) +- `DelaySeconds`: Máximo de 31.536.000 segundos (365 dias) +- `StartTime`: Deve ser o momento atual ou futuro; não pode exceder 365 dias à frente +- Não é possível combinar a flag `tfCronUnset` com os campos `DelaySeconds`, `RepeatCount` ou `StartTime` +- Ao criar um cron, `DelaySeconds` e `RepeatCount` devem ambos existir ou ambos estar ausentes + +### Casos de Erro + +Além dos erros que podem ocorrer em todas as transações, as transações CronSet podem resultar nos seguintes códigos de resultado: + +| Código de Erro | Descrição | +| ------------------ | --------------------------------------------------------------------------------------------------------------- | +| `temDISABLED` | Ocorre se a funcionalidade Cron não estiver habilitada. | +| `temINVALID_FLAG` | Ocorre se flags inválidas estiverem definidas na transação. | +| `temMALFORMED` | Ocorre se a transação estiver malformada com combinações de campos inválidas. | +| `tecEXPIRED` | Ocorre se `StartTime` estiver no passado ou mais de 365 dias no futuro. | +| `tefINTERNAL` | Ocorre se a entrada do ledger da conta estiver ausente. | +| `tefBAD_LEDGER` | Ocorre se o objeto Cron estiver ausente, apontar para uma entrada não-cron, ou se a remoção do diretório do proprietário falhar. | diff --git a/src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-types/depositpreauth.mdx b/src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-types/depositpreauth.mdx new file mode 100644 index 0000000..fcb7a2e --- /dev/null +++ b/src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-types/depositpreauth.mdx @@ -0,0 +1,45 @@ +--- +title: DepositPreauth +description: >- + Uma transação DepositPreauth concede a outra conta pré-aprovação para + entregar pagamentos ao remetente desta transação. +--- +import { Aside } from '@astrojs/starlight/components'; + + + +\[[Source](https://github.com/Xahau/xahaud/blob/dev/src/ripple/app/tx/impl/URIToken.cpp)] + +_(Adicionado pela \[emenda DepositPreauth]\[].)_ + +### Exemplo + +```json +{ + "TransactionType" : "DepositPreauth", + "Account" : "rsUiUMpnrgxQp24dJYZDhmV4bE3aBtQyt8", + "Authorize" : "rEhxGqkqPPSxQ3P25J66ft5TwpzV14k2de", + "Fee" : "10", + "Flags" : 2147483648, + "Sequence" : 2 +} +``` + +### Campos + +| Campo | Tipo JSON | \[Tipo Interno]\[] | Descrição | +| ------------- | --------- | ------------------- | --------------------------------------------------------------------------------------- | +| `Authorize` | String | AccountID | _(Opcional)_ Endereço Xahau do remetente a ser pré-autorizado. | +| `Unauthorize` | String | AccountID | _(Opcional)_ Endereço Xahau do remetente cuja pré-autorização deve ser revogada. | + +Você deve fornecer _ou_ `Authorize` _ou_ `Unauthorize`, mas não ambos. + +### Casos de Erro + +* Uma conta não pode pré-autorizar (ou revogar) seu próprio endereço. Tentar fazer isso falha com o resultado `temCANNOT_PREAUTH_SELF`. +* Tentar pré-autorizar uma conta que já está pré-autorizada falha com o resultado `tecDUPLICATE`. +* Tentar revogar a autorização de uma conta que não está pré-autorizada falha com o resultado `tecNO_ENTRY`. +* Tentar pré-autorizar um endereço que não possui fundos no ledger falha com o resultado `tecNO_TARGET`. +* Adicionar uma autorização cria um objeto DepositPreauth no ledger, que conta para o requisito de reserva do proprietário. Se o remetente da transação não tiver XAH suficiente para cobrir o aumento de reserva, a transação falha com o resultado `tecINSUFFICIENT_RESERVE`. Se a conta já atingiu o número máximo de objetos próprios, a transação falha com o resultado `tecDIR_FULL`. diff --git a/src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-types/escrowcancel.mdx b/src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-types/escrowcancel.mdx new file mode 100644 index 0000000..1415d16 --- /dev/null +++ b/src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-types/escrowcancel.mdx @@ -0,0 +1,42 @@ +--- +title: EscrowCancel +description: Devolve XAH ou IOU em escrow para o remetente. +--- +\[[Fonte](https://github.com/Xahau/xahaud/blob/dev/src/ripple/app/tx/impl/URIToken.cpp)] + +_Adicionado pela \[emenda Escrow]\[]._ + +### Cancelar Usando OfferSequence + +```json +{ + "Account": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn", + "TransactionType": "EscrowCancel", + "Owner": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn", + "OfferSequence": 7, +} +``` + +### Cancelar Usando EscrowID + +```json +{ + "Account": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn", + "TransactionType": "EscrowCancel", + "Owner": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn", + "EscrowID": "49647F0D748DC3FE26BDACBC57F251AADEFFF391403EC9BF87C97F67E9977FB0", +} +``` + +### Campos + +| Campo | Tipo JSON | \[Tipo Interno]\[] | Descrição | +| --------------- | --------- | ------------------ | ---------------------------------------------------------------------------------------------------------------------------------- | +| `Owner` | String | AccountID | Endereço da conta de origem que financiou o pagamento em escrow. | +| `OfferSequence` | Number | UInt32 | _(Opcional)_ Sequência da transação (ou número de Ticket) da \[transação EscrowCreate]\[] que criou o escrow a ser cancelado. | +| `EscrowID` | String | Hash256 | _(Opcional)_ O ID do objeto de ledger Escrow a ser cancelado, como uma string hexadecimal de 64 caracteres. | + +Qualquer conta pode enviar uma transação EscrowCancel. + +* Se a \[transação EscrowCreate]\[] correspondente não especificou um tempo `CancelAfter`, a transação EscrowCancel falha. +* Caso contrário, a transação EscrowCancel falha se o tempo `CancelAfter` for posterior ao tempo de fechamento do ledger fechado mais recentemente. diff --git a/src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-types/escrowcreate.mdx b/src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-types/escrowcreate.mdx new file mode 100644 index 0000000..60dd912 --- /dev/null +++ b/src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-types/escrowcreate.mdx @@ -0,0 +1,43 @@ +--- +title: EscrowCreate +description: Sequestra XAH ou IOU até que o processo de escrow seja concluído ou cancelado. +--- +\[[Fonte](https://github.com/Xahau/xahaud/blob/dev/src/ripple/app/tx/impl/URIToken.cpp)] + +_Adicionado pela \[emenda Escrow]\[]._ + +### Exemplo + +```json +{ + "Account": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn", + "TransactionType": "EscrowCreate", + "Amount" : { + "currency" : "USD", + "value" : "1", + "issuer" : "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn" + }, + "Destination": "rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW", + "CancelAfter": 533257958, + "FinishAfter": 533171558, + "Condition": "A0258020E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855810100", + "DestinationTag": 23480, + "SourceTag": 11747 +} +``` + +### Campos + +| Campo | Tipo JSON | \[Tipo Interno]\[] | Descrição | +| ---------------- | ---------------------------------------------------------------------------------------------------------------------------------- | ------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| `Amount` | [Valor em Moeda](/docs/protocol-reference/data-types/currency-formats/#specifying-currency-amounts) | Amount | Valor a ser deduzido do saldo do remetente e colocado em escrow. Uma vez em escrow, o valor pode ir para o endereço `Destination` (após o tempo `FinishAfter`) ou ser devolvido ao remetente (após o tempo `CancelAfter`). | +| `Destination` | String | AccountID | Endereço para receber o valor em escrow. | +| `CancelAfter` | Number | UInt32 | _(Opcional)_ O momento, em \[segundos desde o Epoch do Ripple]\[], em que este escrow expira. Este valor é imutável; os fundos só podem ser devolvidos ao remetente após este momento. | +| `FinishAfter` | Number | UInt32 | _(Opcional)_ O momento, em \[segundos desde o Epoch do Ripple]\[], em que o valor em escrow pode ser liberado ao destinatário. Este valor é imutável; os fundos não podem ser movimentados até que este momento seja atingido. | +| `Condition` | String | Blob | _(Opcional)_ Valor hexadecimal representando uma [crypto-condition PREIMAGE-SHA-256](https://tools.ietf.org/html/draft-thomas-crypto-conditions-02#section-8.1). Os fundos só podem ser entregues ao destinatário se esta condição for cumprida. | +| `DestinationTag` | Number | UInt32 | _(Opcional)_ Tag arbitrária para especificar melhor o destino deste pagamento em escrow, como um destinatário hospedado no endereço de destino. | + +`CancelAfter` ou `FinishAfter` devem ser especificados. Se ambos forem incluídos, o tempo `FinishAfter` deve ser anterior ao tempo `CancelAfter`. + +Com a \[emenda fix1571]\[] habilitada, é necessário fornecer `FinishAfter`, `Condition`, ou ambos. \[Novo em: rippled 1.0.0]\[] + diff --git a/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/escrowfinish.mdx b/src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-types/escrowfinish.mdx similarity index 94% rename from src/content/docs/br/docs/protocol-reference/transactions/transaction-types/escrowfinish.mdx rename to src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-types/escrowfinish.mdx index 20e5855..981cddb 100644 --- a/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/escrowfinish.mdx +++ b/src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-types/escrowfinish.mdx @@ -1,12 +1,12 @@ --- title: EscrowFinish -description: Deliver XAH or IOU from a held payment to the recipient. +description: Entrega XAH ou IOU de um pagamento retido ao destinatário. --- -\[[Source](https://github.com/Xahau/xahaud/blob/dev/src/ripple/app/tx/impl/URIToken.cpp)] +\[[Fonte](https://github.com/Xahau/xahaud/blob/dev/src/ripple/app/tx/impl/URIToken.cpp)] -_Added by the \[Escrow amendment]\[]._ +_Adicionado pela \[emenda Escrow]\[]._ -### Finish with OfferSequence +### Concluir com OfferSequence ```json { @@ -19,7 +19,7 @@ _Added by the \[Escrow amendment]\[]._ } ``` -### Finish with EscrowID +### Concluir com EscrowID ```json { diff --git a/src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-types/genesismint-emitted-txn.mdx b/src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-types/genesismint-emitted-txn.mdx new file mode 100644 index 0000000..179f63b --- /dev/null +++ b/src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-types/genesismint-emitted-txn.mdx @@ -0,0 +1,57 @@ +--- +title: GenesisMint - (Emitted Txn) +description: >- + A transação GenesisMint é usada para cunhar novos XAH e distribuí-los para + múltiplas contas. Esta transação só pode ser usada pela conta gênesis. +--- +\[[Fonte](https://github.com/ripple/rippled/blob/develop/src/ripple/app/tx/impl/GenesisMint.cpp)] + +_Adicionado pela \[emenda XahauGenesis]\[] e pela \[emenda Hooks]\[]_ + +### Exemplo + +```json +{ + "TransactionType": "GenesisMint", + "Account": "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh", + "GenesisMints": [ + { + "GenesisMint": { + "Destination": "rPT1Sjq2YGrBMTttX4GZHjKu9dyfzbpAYe", + "Amount": "1000000000" + }, + } + ] +} +``` + +### Campos + +| Campo | Tipo JSON | Tipo Interno | Descrição | +| -------------- | --------- | ------------ | -------------------------------------------------------------------------------------- | +| `Account` | String | AccountID | O endereço da conta gênesis que irá cunhar e distribuir XAH. | +| `GenesisMints` | Array | Array | Um array de objetos representando os destinos e quantidades do XAH a ser cunhado. | + +### Objeto GenesisMint + +A transação GenesisMint inclui um array de objetos chamado `GenesisMints`. Cada objeto representa uma conta de destino e a quantidade de XAH a ser cunhada e distribuída para essa conta. + +| Campo | Tipo JSON | Tipo Interno | Descrição | +| ----------------- | --------- | ------------ | -------------------------------------------------------------------------------------- | +| `Destination` | String | AccountID | O endereço da conta que receberá o XAH cunhado. | +| `Amount` | String | Amount | A quantidade de XAH a ser cunhada e distribuída para a conta de destino. | +| `GovernanceFlags` | String | Hash256 | _(Opcional)_ As flags de governança associadas à conta de destino. | +| `GovernanceMarks` | String | Hash256 | _(Opcional)_ As marcações de governança associadas à conta de destino. | + +### Custo Especial de Transação + +A transação GenesisMint possui um custo de transação padrão, que é o custo mínimo exigido para todas as transações. + +### Casos de Erro + +Além dos erros que podem ocorrer em todas as transações, a transação GenesisMint pode resultar nos seguintes códigos de resultado: + +| Código de Erro | Descrição | +| -------------- | ------------------------------------------------------------------------------------------------------ | +| `temDISABLED` | Ocorre se as emendas "Hooks" ou "XahauGenesis" não estiverem habilitadas. | +| `temMALFORMED` | Ocorre se a transação estiver malformada, como campos obrigatórios ausentes ou valores inválidos. | diff --git a/src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-types/import.mdx b/src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-types/import.mdx new file mode 100644 index 0000000..b74274b --- /dev/null +++ b/src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-types/import.mdx @@ -0,0 +1,64 @@ +--- +title: Import +description: >- + Import é uma nova transação que aceita um XPOP da rede principal do XRPL + (network_id=0) ou Testnet (network_id=1) e fornece sincronização de contas. +--- +\[[Fonte](https://github.com/Xahau/xahaud/blob/dev/src/ripple/app/tx/impl/URIToken.cpp)] + +_(Adicionado pela \[emenda Import]\[].)_ + +### Exemplo + +```json +{ + "TransactionType": "Import", + "Sequence": 0, + "Fee": "0", + "Account": "rUn84CUYbNjRoTQ6mSW7BVJPSVJNLb1QLo", + "Blob" : "DEADBEEF" +} +``` + +### Campos + +| Campo | Tipo JSON | \[Tipo Interno]\[] | Descrição | +| ------------- | --------- | ------------------ | ---------------------------------------------------------- | +| `Blob` | String | Blob | Valor hexadecimal representando um XPOP | +| `Issuer` | String | AccountID | (Opcional) Endereço que pode ser usado dentro do Hook. | +| `Destination` | String | AccountID | (Opcional) Endereço que pode ser usado dentro do Hook. | + +### Casos de Erro + +* Se a conta não estiver ativada, o `Sequence` deve ser 0 e o `Fee` também deve ser 0. +* Se a conta estiver ativada, o `Sequence` e o `Fee` são calculados pelo método padrão. +* Se o campo `Issuer` estiver presente, o `Fee` deve ser calculado pelo método padrão. + +### Notas + +_Recomenda-se que, caso você utilize uma `SignerList` ou `RegularKey` para assinar suas transações, configure as chaves das suas contas **PRIMEIRO** antes de tentar realizar o _B2M_ de XAH._ + +* Se a transação interna (xpop) for `AccountSet`, as flags existentes na mainnet serão transferidas para a nova rede. +* Se a transação interna (xpop) for `SetRegularKey` com o campo `RegularKey` omitido ou vazio, e não existir uma lista de signatários para a conta, então a flag `lsfDisableMaster` será definida na conta. +* Se a transação interna (xpop) for `SetRegularKey`, então a flag `lsfPasswordSpent` será definida na conta. +* `TicketSequence` não está disponível no `Import`. + +### Importação para o Emissor + +Para emissores, há etapas adicionais a seguir antes que os detentores de ativos possam importar transações. + +Primeiramente, os emissores precisam instalar um hook. Há duas opções: `B2MNFToken` ou `B2MPayment`. + +#### B2MNFToken + +Uma transação `NFTokenBurn` na mainnet resultará em uma transação `URITokenMint` na rede. + +> c hook: https://example.com + +#### B2MPayment + +Uma transação `Payment` na mainnet para o Emissor resultará em uma transação `Payment` do Emissor na rede. + +> c hook: https://example.com + +_Observe que o processo de importação para o emissor envolve tipos de transação específicos e requer configuração cuidadosa. Certifique-se sempre de que os hooks estejam configurados corretamente e que as transações sejam válidas para as operações pretendidas._ diff --git a/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/index.mdx b/src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-types/index.mdx similarity index 100% rename from src/content/docs/br/docs/protocol-reference/transactions/transaction-types/index.mdx rename to src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-types/index.mdx diff --git a/src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-types/invoke.mdx b/src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-types/invoke.mdx new file mode 100644 index 0000000..99ee6f4 --- /dev/null +++ b/src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-types/invoke.mdx @@ -0,0 +1,40 @@ +--- +title: Invoke +description: >- + Uma transação Invoke é usada para chamar um hook, que é um trecho de código + executado em resposta a determinadas operações no ledger. +--- +\[[Source](https://github.com/ripple/rippled/blob/develop/src/ripple/app/tx/impl/Invoke.cpp)] + +_(Adicionado pela [emenda Hooks][].)_ + +### Exemplo + +```json +{ + "TransactionType": "Invoke", + "Account": "rWYkbWkCeg8dP6rXALnjgZSjjLyih5NXm", + "Blob": "697066733A2F2F4445414442454546", + "Destination": "rPT1Sjq2YGrBMTttX4GZHjKu9dyfzbpAYe" +} +``` + +| Campo | Tipo JSON | \[Tipo Interno]\[] | Obrigatório? | Descrição | +| ---------------- | --------- | ------------------ | ------------ | -------------------------------------------------------------------------------------- | +| `Account` | String | AccountID | Sim | O endereço da conta que está invocando o hook. | +| `Blob` | String | Blob | Não | Um blob de dados passado ao hook. (máximo de 128k bytes) | +| `Destination` | String | AccountID | Não | O endereço da conta que é o destino do hook. | + +### Custo Especial de Transação + +A transação Invoke possui um custo de transação padrão, acrescido de um custo adicional baseado no tamanho do campo Blob. + +### Casos de Erro + +Além dos erros que podem ocorrer em todas as transações, as transações Invoke podem resultar nos seguintes códigos de resultado: + +| Código de Erro | Descrição | +| --------------- | -------------------------------------------------------------------------------------- | +| `temDISABLED` | Ocorre se a emenda Hooks não estiver habilitada. | +| `temMALFORMED` | Ocorre se o campo Blob for maior que 128k bytes. | +| `terNO_ACCOUNT` | Ocorre se a conta remetente ou a conta de destino não existir. | diff --git a/src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-types/offercancel.mdx b/src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-types/offercancel.mdx new file mode 100644 index 0000000..ccfd513 --- /dev/null +++ b/src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-types/offercancel.mdx @@ -0,0 +1,44 @@ +--- +title: OfferCancel +description: Uma transação OfferCancel remove um objeto Offer do Xahau. +--- +\[[Source](https://github.com/Xahau/xahaud/blob/dev/src/ripple/app/tx/impl/URIToken.cpp)] + +### Cancelar com OfferSequence + +```json +{ + "TransactionType": "OfferCancel", + "Account": "ra5nK24KXen9AHvsdFTKHSANinZseWnPcX", + "Fee": "12", + "Flags": 0, + "LastLedgerSequence": 7108629, + "OfferSequence": 6, + "Sequence": 7 +} +``` + +### Cancelar com OfferID + +```json +{ + "TransactionType": "OfferCancel", + "Account": "ra5nK24KXen9AHvsdFTKHSANinZseWnPcX", + "Fee": "12", + "Flags": 0, + "LastLedgerSequence": 7108629, + "OfferID": "49647F0D748DC3FE26BDACBC57F251AADEFFF391403EC9BF87C97F67E9977FB0", + "Sequence": 7 +} +``` + +### Campos + +| Campo | Tipo JSON | \[Tipo Interno]\[] | Descrição | +| --------------- | --------- | ------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| `OfferSequence` | Number | UInt32 | _(Opcional)_ O número de sequência (ou número de Ticket) de uma transação OfferCreate anterior. Se especificado, cancela qualquer objeto offer no ledger que foi criado por essa transação. Não é considerado um erro se a offer especificada não existir. | +| `OfferID` | String | Hash256 | _(Opcional)_ O ID do objeto Offer no ledger a ser cancelado, como uma string hexadecimal de 64 caracteres. | + +_Dica:_ Para remover uma offer antiga e substituí-la por uma nova, você pode usar uma \[transação OfferCreate]\[] com o parâmetro `OfferSequence`, em vez de usar OfferCancel seguido de outro OfferCreate. + +O método OfferCancel retorna `tesSUCCESS` mesmo que não encontre uma offer com o número de sequência correspondente. diff --git a/src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-types/offercreate.mdx b/src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-types/offercreate.mdx new file mode 100644 index 0000000..5721ed2 --- /dev/null +++ b/src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-types/offercreate.mdx @@ -0,0 +1,68 @@ +--- +title: OfferCreate +description: >- + Uma transação OfferCreate coloca uma Oferta na + exchange descentralizada. +--- +\[[Fonte](https://github.com/Xahau/xahaud/blob/dev/src/ripple/app/tx/impl/URIToken.cpp)] + +### Exemplo + +```json +{ + "TransactionType": "OfferCreate", + "Account": "ra5nK24KXen9AHvsdFTKHSANinZseWnPcX", + "Fee": "12", + "Flags": 0, + "LastLedgerSequence": 7108682, + "Sequence": 8, + "TakerGets": "6000000", + "TakerPays": { + "currency": "GKO", + "issuer": "ruazs5h1qEsqpke88pcqnaseXdm6od2xc", + "value": "2" + } +} +``` + +### Campos + +| Campo | Tipo JSON | \[Tipo Interno]\[] | Descrição | +| --------------- | ---------------------------------------------------------------------------------------------------------------------------------- | ------------------- | ------------------------------------------------------------------------------------------------------ | +| `Expiration` | Number | UInt32 | _(Opcional)_ Momento após o qual a Oferta deixa de estar ativa, em \[segundos desde a Época Ripple]\[]. | +| `OfferSequence` | Number | UInt32 | _(Opcional)_ Uma Oferta a ser excluída primeiro, especificada da mesma forma que \[OfferCancel]\[]. | +| `OfferID` | String | Hash256 | _(Opcional)_ O ID do objeto de Oferta no ledger a ser cancelado, como uma string hexadecimal de 64 caracteres. | +| `TakerGets` | [Valor em Moeda](/docs/protocol-reference/data-types/currency-formats/#specifying-currency-amounts) | Amount | O valor e o tipo de moeda sendo vendida. | +| `TakerPays` | [Valor em Moeda](/docs/protocol-reference/data-types/currency-formats/#specifying-currency-amounts) | Amount | O valor e o tipo de moeda sendo comprada. | + +### Flags do OfferCreate + +Transações do tipo OfferCreate suportam valores adicionais no campo `Flags`, conforme abaixo: + +| Nome da Flag | Valor Hex | Valor Decimal | Descrição | +| --------------------- | ------------ | ------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `tfPassive` | `0x00010000` | 65536 | Se habilitado, a Oferta não consome Ofertas que correspondam exatamente a ela e, em vez disso, torna-se um objeto Oferta no ledger. Ainda assim, consome Ofertas que a cruzem. | +| `tfImmediateOrCancel` | `0x00020000` | 131072 | Trata a Oferta como uma [ordem Immediate or Cancel](http://en.wikipedia.org/wiki/Immediate_or_cancel). A Oferta nunca cria um \[objeto Oferta]\[] no ledger: ela apenas negocia o máximo possível consumindo Ofertas existentes no momento em que a transação é processada. Se nenhuma Oferta corresponder, ela é executada "com sucesso" sem negociar nada. Nesse caso, a transação ainda usa o código de resultado `tesSUCCESS`. | +| `tfFillOrKill` | `0x00040000` | 262144 | Trata a oferta como uma [ordem Fill or Kill](http://en.wikipedia.org/wiki/Fill_or_kill). A Oferta nunca cria um \[objeto Oferta]\[] no ledger e é cancelada se não puder ser totalmente preenchida no momento da execução. Por padrão, isso significa que o proprietário deve receber o valor total de `TakerPays`; se a flag `tfSell` estiver habilitada, o proprietário deve ser capaz de gastar todo o valor de `TakerGets`. | +| `tfSell` | `0x00080000` | 524288 | Troca todo o valor de `TakerGets`, mesmo que isso implique obter mais do que o valor de `TakerPays` em troca. | + +### Casos de Erro + +| Código de Erro | Descrição | +| ------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `temINVALID_FLAG` | Ocorre se a transação especifica tanto `tfImmediateOrCancel` quanto `tfFillOrKill`. | +| `tecEXPIRED` | Ocorre se a transação especifica um tempo de `Expiration` que já passou. | +| `tecKILLED` | Ocorre se a transação especifica `tfFillOrKill` e o valor total não pode ser preenchido. Se a _\[emenda ImmediateOfferKilled]\[]_ estiver habilitada, este código de resultado também ocorre quando a transação especifica `tfImmediateOrCancel` e é executada sem mover fundos (anteriormente, isso retornaria `tesSUCCESS`). | +| `temBAD_EXPIRATION` | Ocorre se a transação contém um campo `Expiration` com formato inválido. | +| `temBAD_SEQUENCE` | Ocorre se a transação contém um `OfferSequence` com formato inválido ou maior que o próprio número de `Sequence` da transação. | +| `temBAD_OFFER` | Ocorre se a Oferta tenta trocar XAH por XAH ou tenta negociar um valor inválido ou negativo de um token. | +| `temREDUNDANT` | Ocorre se a transação especifica um token pelo mesmo token (mesmo emissor e código de moeda). | +| `temBAD_CURRENCY` | Ocorre se a transação especifica um token com o código de moeda "XAH". | +| `temBAD_ISSUER` | Ocorre se a transação especifica um token com um valor de `issuer` inválido. | +| `tecNO_ISSUER` | Ocorre se a transação especifica um token cujo valor de `issuer` não é uma conta com fundos no ledger. | +| `tecFROZEN` | Ocorre se a transação envolve um token em uma linha de confiança congelada (incluindo congelamentos locais e globais). | +| `tecUNFUNDED_OFFER` | Ocorre se o proprietário não possui um valor positivo da moeda `TakerGets`. (Exceção: se `TakerGets` especifica um token que o proprietário emite, a transação pode ter sucesso.) | +| `tecNO_LINE` | Ocorre se a transação envolve um token cujo emissor usa Linhas de Confiança Autorizadas e a linha de confiança necessária não existe. | +| `tecNO_AUTH` | Ocorre se a transação envolve um token cujo emissor usa Linhas de Confiança Autorizadas e a linha de confiança que receberia os tokens existe, mas não foi autorizada. | +| `tecINSUF_RESERVE_OFFER` | Ocorre se o proprietário não tem XAH suficiente para atender ao requisito de reserva para adicionar um novo objeto Oferta ao ledger, e a transação não converteu nenhuma moeda. (Se a transação negociou qualquer valor com sucesso, ela é concluída com o código de resultado `tesSUCCESS`, mas não cria um objeto Oferta no ledger para o restante.) | +| `tecDIR_FULL` | Ocorre se o proprietário possui muitos itens no ledger ou o livro de ordens já contém muitas Ofertas na mesma taxa de câmbio. | diff --git a/src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-types/payment.mdx b/src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-types/payment.mdx new file mode 100644 index 0000000..e8e2315 --- /dev/null +++ b/src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-types/payment.mdx @@ -0,0 +1,113 @@ +--- +title: Payment +description: >- + Uma transação Payment representa uma transferência de valor de uma conta para + outra. (Dependendo do caminho percorrido, isso pode envolver trocas adicionais + de valor, que ocorrem atomicamente.) Esta transação +--- +[\[Fonte\]](https://github.com/ripple/rippled/blob/5425a90f160711e46b2c1f1c93d68e5941e4bfb6/src/ripple/app/transactors/Payment.cpp) + +### Exemplo + +```json +{ + "TransactionType" : "Payment", + "Account" : "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn", + "Destination" : "ra5nK24KXen9AHvsdFTKHSANinZseWnPcX", + "Amount" : { + "currency" : "USD", + "value" : "1", + "issuer" : "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn" + }, + "Fee": "12", + "Flags": 2147483648, + "Sequence": 2, +} +``` + +| Campo | Tipo JSON | \[Tipo Interno]\[] | Descrição | +| ---------------- | ---------------------------------------------------------------------------------------------------------------------------------- | ------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| `Amount` | [Valor de Moeda](/docs/protocol-reference/data-types/currency-formats/#specifying-currency-amounts) | Amount | A quantidade de moeda a ser entregue. Para valores não-XAH, os nomes dos campos aninhados DEVEM estar em letras minúsculas. Se a flag `tfPartialPayment` estiver definida, entrega _até_ esse valor em vez do exato. | +| `Destination` | String | AccountID | O endereço único da conta que receberá o pagamento. | +| `DestinationTag` | Number | UInt32 | _(Opcional)_ Tag arbitrária que identifica o motivo do pagamento ao destino, ou um destinatário hospedado a ser pago. | +| `InvoiceID` | String | Hash256 | _(Opcional)_ Hash arbitrário de 256 bits representando um motivo ou identificador específico para este pagamento. | +| `Paths` | Array de arrays de caminho | PathSet | (Opcional, preenchível automaticamente) Array de caminhos de pagamento a serem usados nesta transação. Deve ser omitido em transações XAH-para-XAH. | +| `SendMax` | [Valor de Moeda](/docs/protocol-reference/data-types/currency-formats/#specifying-currency-amounts) | Amount | _(Opcional)_ Maior valor de moeda de origem que esta transação pode custar, incluindo taxas de transferência, taxas de câmbio e [slippage](http://en.wikipedia.org/wiki/Slippage_\(finance\)). Não inclui o XAH destruído como custo de envio da transação. Para valores não-XAH, os nomes dos campos aninhados DEVEM estar em letras minúsculas. Deve ser fornecido para pagamentos entre moedas/emissores diferentes. Deve ser omitido em pagamentos XAH-para-XAH. | +| `DeliverMin` | \[Valor de Moeda]\[] | Amount | _(Opcional)_ Valor mínimo de moeda de destino que esta transação deve entregar. Válido apenas para pagamentos parciais. Para valores não-XAH, os nomes dos campos aninhados estão em letras minúsculas. | + +### Tipos de Pagamentos + +O tipo de transação Payment é uma ferramenta de uso geral que pode representar vários tipos diferentes de ações abstratas. Você pode identificar o tipo de transação com base nos campos da transação, conforme descrito na tabela abaixo: + +| Tipo de pagamento | `Amount` | `SendMax` | `Paths` | `Address` = `Destination`? | Descrição | +| --------------------------------- | ------------------------------- | ------------------------------- | ---------------- | -------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Pagamento direto XAH-para-XAH | String (XAH) | Omitido | Omitido | Não | Transfere XAH diretamente de uma conta para outra. Sempre entrega o valor exato. Nenhuma taxa se aplica além do custo básico da transação. | +| Criação ou resgate de tokens | Objeto | Objeto (opcional) | Opcional | Não | Aumenta ou diminui a quantidade de uma moeda ou ativo não-XAH rastreado no Xahau. Taxas de transferência e congelamentos não se aplicam ao enviar e resgatar diretamente. | +| Pagamento entre moedas | Objeto (não-XAH) / String (XAH) | Objeto (não-XAH) / String (XAH) | Geralmente obrigatório | Não | Envia tokens de um titular para outro. O `Amount` ou `SendMax` pode ser XAH ou tokens, mas não podem ser ambos XAH. Esses pagamentos passam pelo emissor e podem percorrer caminhos mais longos por vários intermediários se a transação especificar um conjunto de caminhos. Taxas de transferência definidas pelo(s) emissor(es) se aplicam a este tipo de transação. Essas transações consomem ofertas na exchange descentralizada para conectar diferentes moedas, ou possivelmente até moedas com o mesmo código e emissores diferentes. | +| Pagamento parcial | Objeto (não-XAH) / String (XAH) | Objeto (não-XAH) / String (XAH) | Geralmente obrigatório | Não | Envia _até_ um valor específico em qualquer moeda. Usa a flag `tfPartialPayment`. Pode incluir um valor `DeliverMin` especificando o mínimo que a transação deve entregar para ser bem-sucedida; se a transação não especificar `DeliverMin`, ela pode ter sucesso entregando _qualquer valor positivo_. | +| Conversão de moeda | Objeto (não-XAH) / String (XAH) | Objeto (não-XAH) / String (XAH) | Obrigatório | Sim | Consome ofertas na exchange descentralizada para converter uma moeda em outra, possivelmente aproveitando oportunidades de [arbitragem](https://en.wikipedia.org/wiki/Arbitrage). O `Amount` e o `SendMax` não podem ser ambos XAH. Também chamado de _pagamento circular_ porque entrega dinheiro ao remetente. A API de Dados rastreia este tipo de transação como uma "troca" e não um "pagamento". | + +### Valores especiais de emissor para SendMax e Amount + +Na maioria das vezes, o campo `issuer` de um \[Valor de Moeda]\[] não-XAH indica o emissor de um token. No entanto, ao descrever pagamentos, existem regras especiais para o campo `issuer` nos campos `Amount` e `SendMax` de um pagamento. + +* Existe apenas um saldo entre dois endereços para o mesmo código de moeda. Isso significa que, às vezes, o campo `issuer` de um valor na verdade se refere a uma contraparte, em vez do endereço que emitiu o token. +* Quando o campo `issuer` do campo de destino `Amount` corresponde ao endereço de `Destination`, ele é tratado como um caso especial significando "qualquer emissor que o destino aceite." Isso inclui todos os endereços para os quais o destino possui linhas de confiança com limite positivo, bem como tokens com o mesmo código de moeda emitidos pelo destino. +* Quando o campo `issuer` do campo `SendMax` corresponde ao endereço da conta de origem, ele é tratado como um caso especial significando "qualquer emissor que a origem possa usar." Isso inclui a criação de novos tokens em linhas de confiança que outras contas estenderam à conta de origem, e o envio de tokens que a conta de origem detém de outros emissores. + +### Criando Contas + +O tipo de transação Payment pode criar novas contas no Xahau enviando XAH suficiente para um endereço sem fundos. Outras transações para endereços sem fundos sempre falham. + +Para mais informações, consulte Contas. + +### Caminhos + +Se presente, o campo `Paths` deve conter um _conjunto de caminhos_ — um array de arrays de caminhos. Cada caminho individual representa uma forma pela qual o valor pode fluir do remetente ao destinatário por meio de várias contas intermediárias e livros de ordens. Uma única transação pode potencialmente usar múltiplos caminhos, por exemplo, se a transação trocar moeda usando vários livros de ordens diferentes para obter a melhor taxa. + +Você deve omitir o campo `Paths` para pagamentos diretos, incluindo: + +* Uma transferência XAH-para-XAH. +* Uma transferência direta em uma linha de confiança que conecta o remetente e o destinatário. + +Se o campo `Paths` for fornecido, o servidor decide no momento do processamento da transação quais caminhos usar, a partir do conjunto fornecido mais um _caminho padrão_ (a forma mais direta possível de conectar as contas especificadas). Essa decisão é determinística e tenta minimizar os custos, mas não há garantia de que seja perfeita. + +O campo `Paths` não deve ser um array vazio, nem um array cujos membros sejam todos arrays vazios. + +Para mais informações, consulte Caminhos. + +### Flags de Pagamento + +Transações do tipo Payment suportam valores adicionais no campo `Flags`, da seguinte forma: + +| Nome da Flag | Valor Hex | Valor Decimal | Descrição | +| ------------------ | ------------ | ------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| `tfNoDirectRipple` | `0x00010000` | 65536 | Não usar o caminho padrão; usar apenas os caminhos incluídos no campo `Paths`. Isso tem o objetivo de forçar a transação a aproveitar oportunidades de arbitragem. A maioria dos clientes não precisa disso. | +| `tfPartialPayment` | `0x00020000` | 131072 | Se o `Amount` especificado não puder ser enviado sem gastar mais do que `SendMax`, reduz o valor recebido em vez de falhar completamente. Consulte Pagamentos Parciais para mais detalhes. | +| `tfLimitQuality` | `0x00040000` | 262144 | Usar apenas caminhos onde todas as conversões tenham uma proporção entrada:saída igual ou melhor que a proporção `Amount`:`SendMax`. Consulte Limite de Qualidade para detalhes. | + +### Pagamentos Parciais + +Um pagamento parcial permite que um pagamento seja bem-sucedido reduzindo o valor recebido. Pagamentos parciais são úteis para devolver pagamentos sem incorrer em custos adicionais para si mesmo. No entanto, pagamentos parciais também podem ser usados para explorar integrações que ingenuamente assumem que o campo `Amount` de uma transação bem-sucedida sempre descreve o valor exato entregue. + +Um pagamento parcial é qualquer \[transação Payment]\[] com a flag `tfPartialPayment` habilitada. Um pagamento parcial pode ser bem-sucedido se entregar qualquer valor positivo maior ou igual ao seu campo `DeliverMin` (ou qualquer valor positivo se `DeliverMin` não for especificado) sem enviar mais do que o valor de `SendMax`. + +O campo `delivered_amount` nos metadados de um pagamento indica o valor de moeda efetivamente recebido pela conta de destino. + +Para mais informações, consulte o artigo completo sobre Pagamentos Parciais. + +### Limite de Qualidade + +O Xahau define a "qualidade" de uma troca de moeda como a proporção do valor numérico de entrada pelo valor numérico de saída. Por exemplo, se você gasta $2 USD para receber £1 GBP, então a "qualidade" dessa troca é `0.5`. + +A flag `tfLimitQuality` permite definir uma qualidade mínima de conversões que você está disposto a aceitar. Esse limite de qualidade é definido como o `Amount` de destino dividido pelo valor de `SendMax` (apenas os valores numéricos, independentemente da moeda). Quando definida, o mecanismo de processamento de pagamentos evita usar qualquer caminho cuja qualidade (taxa de conversão) seja pior (numericamente inferior) que o limite de qualidade. + +Por si só, a flag `tfLimitQuality` reduz o número de situações em que uma transação pode ser bem-sucedida. Especificamente, ela rejeita pagamentos onde alguma parte do pagamento usa uma conversão desfavorável, mesmo que a qualidade _média_ geral das conversões no pagamento seja igual ou melhor que o limite de qualidade. Se um pagamento for rejeitado dessa forma, o resultado da transação é `tecPATH_DRY`. + +Considere o seguinte exemplo. Se estou tentando enviar a você 100 yuans chineses (`Amount` = 100 CNY) por 20 dólares americanos (`SendMax` = 20 USD) ou menos, então o limite de qualidade é `5`. Imagine que um trader está oferecendo ¥95 por $15 (uma proporção de cerca de `6,3` CNY por USD), mas a próxima melhor oferta no mercado é ¥5 por $2 (uma proporção de `2,5` CNY por USD). Se eu aceitasse ambas as ofertas para enviar a você 100 CNY, custaria 17 USD, para uma qualidade média de cerca de `5,9`. + +Sem a flag `tfLimitQuality` definida, essa transação seria bem-sucedida, pois os $17 que me custaria estão dentro do meu `SendMax` especificado. No entanto, com a flag `tfLimitQuality` habilitada, a transação falharia, pois o caminho para aceitar a segunda oferta tem uma qualidade de `2,5`, que é pior que o limite de qualidade de `5`. + +A flag `tfLimitQuality` é mais útil quando combinada com pagamentos parciais. Quando tanto `tfPartialPayment` quanto `tfLimitQuality` estão definidos em uma transação, ela entrega o máximo possível do `Amount` de destino, sem usar conversões piores que o limite de qualidade. + +No exemplo acima com uma oferta de ¥95/$15 e uma oferta de ¥5/$2, a situação é diferente se minha transação tiver `tfPartialPayment` e `tfLimitQuality` habilitados. Se mantivermos meu `SendMax` de 20 USD e um `Amount` de destino de 100 CNY, o limite de qualidade ainda é `5`. No entanto, como estou fazendo um pagamento parcial, a transação envia o máximo possível em vez de falhar se o valor total de destino não puder ser enviado. Isso significa que minha transação consome a oferta de ¥95/$15, cuja qualidade é cerca de `6,3`, mas rejeita a oferta de ¥5/$2 porque a qualidade dessa oferta de `2,5` é pior que o limite de qualidade de `5`. No final, minha transação entrega apenas ¥95 em vez dos ¥100 completos, mas evita desperdiçar dinheiro em taxas de câmbio desfavoráveis. diff --git a/src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-types/paymentchannelclaim.mdx b/src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-types/paymentchannelclaim.mdx new file mode 100644 index 0000000..c14cffa --- /dev/null +++ b/src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-types/paymentchannelclaim.mdx @@ -0,0 +1,60 @@ +--- +title: PaymentChannelClaim +description: >- + Reivindique um Valor de um canal de pagamento, ajuste a expiração do canal, + ou ambos. Esta transação pode ser usada de formas diferentes dependendo do + papel do remetente na transação no canal especificado: +--- +[\[Fonte\]](https://github.com/ripple/rippled/blob/master/src/ripple/app/tx/impl/PayChan.cpp) + +_Adicionado pela \[emenda PayChan]\[]._ + +O **endereço de origem** de um canal pode: + +* Enviar Valor do canal para o destino _com ou sem_ uma Reivindicação assinada. +* Configurar o canal para expirar assim que o `SettleDelay` do canal tiver passado. +* Limpar um tempo de `Expiration` pendente. +* Fechar um canal imediatamente, com ou sem processar uma reivindicação primeiro. O endereço de origem não pode fechar o canal imediatamente se o canal ainda possui Valor restante. + +O **endereço de destino** de um canal pode: + +* Receber Valor do canal usando uma Reivindicação assinada. +* Fechar o canal imediatamente após processar uma Reivindicação, devolvendo qualquer Valor não reivindicado à origem do canal. + +**Qualquer endereço** que envie esta transação pode: + +* Causar o fechamento de um canal se seu tempo de `Expiration` ou `CancelAfter` for anterior ao tempo de fechamento do ledger anterior. Qualquer transação PaymentChannelClaim válida tem esse efeito independentemente do conteúdo da transação. + +### Exemplo + +```json +{ + "Channel": "C1AE6DDDEEC05CF2978C0BAD6FE302948E9533691DC749DCDD3B9E5992CA6198", + "Amount" : { + "currency" : "USD", + "value" : "1", + "issuer" : "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn" + }, + "Signature": "30440220718D264EF05CAED7C781FF6DE298DCAC68D002562C9BF3A07C1E721B420C0DAB02203A5A4779EF4D2CCC7BC3EF886676D803A9981B928D3B8ACA483B80ECA3CD7B9B", + "PublicKey": "32D2471DB72B27E3310F355BB33E339BF26F8392D5A93D3BC0FC3B566612DA0F0A" +} +``` + +| Campo | Tipo JSON | \[Tipo Interno]\[] | Descrição | +| ----------- | ---------------------------------------------------------------------------------------------------------------------------------- | ------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `Channel` | String | Hash256 | O ID único do canal, como uma string hexadecimal de 64 caracteres. | +| `Balance` | [Valor em Moeda](/docs/protocol-reference/data-types/currency-formats/#specifying-currency-amounts) | Amount | _(Opcional)_ Valor total entregue por este canal após o processamento desta reivindicação. Necessário para entregar Valor. Deve ser maior que o valor total já entregue pelo canal, mas não superior ao `Amount` da reivindicação assinada. Deve ser fornecido exceto ao fechar o canal. | +| `Amount` | [Valor em Moeda](/docs/protocol-reference/data-types/currency-formats/#specifying-currency-amounts) | Amount | _(Opcional)_ O valor autorizado pela `Signature`. Deve corresponder ao valor na mensagem assinada. Este é o valor acumulado de Valor que pode ser dispensado pelo canal, incluindo XAH previamente resgatado. | +| `Signature` | String | Blob | _(Opcional)_ A assinatura desta reivindicação, em hexadecimal. A mensagem assinada contém o ID do canal e o valor da reivindicação. Obrigatório, a menos que o remetente da transação seja o endereço de origem do canal. | +| `PublicKey` | String | Blob | _(Opcional)_ A chave pública usada para a assinatura, em hexadecimal. Deve corresponder à `PublicKey` armazenada no ledger para o canal. Obrigatório, a menos que o remetente da transação seja o endereço de origem do canal e o campo `Signature` seja omitido. (A transação inclui a chave pública para que o `rippled` possa verificar a validade da assinatura antes de tentar aplicar a transação ao ledger.) | + +Se o canal de pagamento foi criado antes de a emenda fixPayChanRecipientOwnerDir ser habilitada (em 01/05/2020), é possível que o destino do canal de pagamento tenha sido excluído e não exista atualmente no ledger. Se o destino foi excluído, a conta de origem não pode enviar XAH do canal ao destino; em vez disso, a transação falha com `tecNO_DST`. (E, claro, a conta excluída não pode enviar nenhuma transação.) Outros usos deste tipo de transação não são afetados quando a conta de destino foi excluída, incluindo o ajuste da expiração do canal, o fechamento de um canal sem Valor, ou a remoção de um canal que passou seu tempo de expiração. + +### Flags de PaymentChannelClaim + +Transações do tipo PaymentChannelClaim suportam valores adicionais no campo `Flags`, como segue: + +| Nome da Flag | Valor Hex | Valor Decimal | Descrição | +| --------- | ------------ | ------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `tfRenew` | `0x00010000` | 65536 | Limpa o tempo de `Expiration` do canal. (`Expiration` é diferente do tempo imutável `CancelAfter` do canal.) Apenas o endereço de origem do canal de pagamento pode usar esta flag. | +| `tfClose` | `0x00020000` | 131072 | Solicita o fechamento do canal. Apenas os endereços de origem e destino do canal podem usar esta flag. Esta flag fecha o canal imediatamente se não houver mais Valor alocado após o processamento da reivindicação atual, ou se o endereço de destino a utilizar. Se o endereço de origem usar esta flag enquanto o canal ainda possui Valor, isso agenda o fechamento do canal após `SettleDelay` segundos. (Especificamente, isso define a `Expiration` do canal como o tempo de fechamento do ledger anterior mais o tempo de `SettleDelay` do canal, a menos que o canal já tenha um tempo de `Expiration` anterior.) Se o endereço de destino usar esta flag enquanto o canal ainda possui Valor, qualquer Valor restante após o processamento da reivindicação é devolvido ao endereço de origem. | diff --git a/src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-types/paymentchannelcreate.mdx b/src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-types/paymentchannelcreate.mdx new file mode 100644 index 0000000..15b207d --- /dev/null +++ b/src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-types/paymentchannelcreate.mdx @@ -0,0 +1,40 @@ +--- +title: PaymentChannelCreate +description: >- + Cria um canal de pagamento e o financia com um Amount. O endereço que envia + esta transação torna-se o "endereço de origem" do canal de pagamento. +--- +[\[Fonte\]](https://github.com/Xahau/xahaud/blob/master/src/ripple/app/tx/impl/PayChan.cpp) + +_Adicionado pela \[emenda PayChan]\[]._ + +### Exemplo + +```json +{ + "Account": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn", + "TransactionType": "PaymentChannelCreate", + "Amount" : { + "currency" : "USD", + "value" : "1", + "issuer" : "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn" + }, + "Destination": "rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW", + "SettleDelay": 86400, + "PublicKey": "32D2471DB72B27E3310F355BB33E339BF26F8392D5A93D3BC0FC3B566612DA0F0A", + "CancelAfter": 533171558, + "DestinationTag": 23480, + "SourceTag": 11747 +} +``` + +| Campo | Tipo JSON | \[Tipo Interno]\[] | Descrição | +| ---------------- | ---------------------------------------------------------------------------------------------------------------------------------- | ------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `Amount` | [Valor em Moeda](/docs/protocol-reference/data-types/currency-formats/#specifying-currency-amounts) | Amount | Valor a ser deduzido do saldo do remetente e reservado neste canal. Enquanto o canal estiver aberto, o Amount só pode ser enviado ao endereço `Destination`. Quando o canal for fechado, qualquer Amount não reivindicado é devolvido ao saldo do endereço de origem. | +| `Destination` | String | AccountID | Endereço para receber reivindicações contra este canal. Também conhecido como "endereço de destino" do canal. Não pode ser o mesmo que o remetente (`Account`). | +| `SettleDelay` | Number | UInt32 | Tempo que o endereço de origem deve aguardar antes de fechar o canal caso haja Amount não reivindicado. | +| `PublicKey` | String | Blob | A chave pública de 33 bytes do par de chaves que a origem usará para assinar reivindicações contra este canal, em hexadecimal. Pode ser qualquer chave pública secp256k1 ou Ed25519. Para mais informações sobre pares de chaves, consulte Derivação de Chaves. | +| `CancelAfter` | Number | UInt32 | _(Opcional)_ O momento, em \[segundos desde a Época Ripple]\[], em que este canal expira. Qualquer transação que modifique o canal após este momento o fecha sem outros efeitos. Este valor é imutável; o canal pode ser fechado antes deste momento, mas não pode permanecer aberto após ele. | +| `DestinationTag` | Number | UInt32 | _(Opcional)_ Tag arbitrária para especificar melhor o destino deste canal de pagamento, como um destinatário hospedado no endereço de destino. | + +Se a conta `Destination` estiver bloqueando canais de pagamento recebidos, a transação falha com o código de resultado `tecNO_PERMISSION`. _(Requer a \[emenda DisallowIncoming]\[] :not_enabled:)_ diff --git a/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/paymentchannelfund.mdx b/src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-types/paymentchannelfund.mdx similarity index 55% rename from src/content/docs/br/docs/protocol-reference/transactions/transaction-types/paymentchannelfund.mdx rename to src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-types/paymentchannelfund.mdx index c12bf58..7616e7e 100644 --- a/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/paymentchannelfund.mdx +++ b/src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-types/paymentchannelfund.mdx @@ -1,15 +1,15 @@ --- title: PaymentChannelFund description: >- - Add additional Amount to an open payment channel, and optionally update the - expiration time of the channel. Only the source address of the channel can use - this transaction. + Adiciona um valor adicional a um canal de pagamento aberto e, opcionalmente, + atualiza o tempo de expiração do canal. Apenas o endereço de origem do canal + pode utilizar esta transação. --- -[\[Source\]](https://github.com/ripple/rippled/blob/master/src/ripple/app/tx/impl/PayChan.cpp) +[\[Fonte\]](https://github.com/ripple/rippled/blob/master/src/ripple/app/tx/impl/PayChan.cpp) -_Added by the \[PayChan amendment]\[]._ +_Adicionado pela \[emenda PayChan]\[]._ -### Example +### Exemplo ```json { @@ -25,22 +25,22 @@ _Added by the \[PayChan amendment]\[]._ } ``` -| Field | JSON Type | \[Internal Type]\[] | Description | +| Campo | Tipo JSON | \[Tipo Interno]\[] | Descrição | | ------------ | ---------------------------------------------------------------------------------------------------------------------------------- | ------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `Channel` | String | Hash256 | The unique ID of the channel to fund, as a 64-character hexadecimal string. | -| `Amount` | [Currency Amount](/docs/protocol-reference/data-types/currency-formats/#specifying-currency-amounts) | Amount | Amount to add to the channel. Must be a positive amount. | -| `Expiration` | Number | UInt32 | _(Optional)_ New `Expiration` time to set for the channel, in \[seconds since the Ripple Epoch]\[]. This must be later than either the current time plus the `SettleDelay` of the channel, or the existing `Expiration` of the channel. After the `Expiration` time, any transaction that would access the channel closes the channel without taking its normal action. Any unspent Amount is returned to the source address when the channel closes. (`Expiration` is separate from the channel's immutable `CancelAfter` time.) For more information, see the PayChannel ledger object type. | +| `Channel` | String | Hash256 | O ID único do canal a ser financiado, como uma string hexadecimal de 64 caracteres. | +| `Amount` | [Valor em Moeda](/docs/protocol-reference/data-types/currency-formats/#specifying-currency-amounts) | Amount | Valor a ser adicionado ao canal. Deve ser um valor positivo. | +| `Expiration` | Number | UInt32 | _(Opcional)_ Novo tempo de `Expiration` a ser definido para o canal, em \[segundos desde o Epoch Ripple]\[]. Deve ser posterior ao tempo atual mais o `SettleDelay` do canal, ou à `Expiration` existente do canal. Após o tempo de `Expiration`, qualquer transação que acesse o canal fecha o canal sem executar sua ação normal. Qualquer valor não gasto é devolvido ao endereço de origem quando o canal é fechado. (`Expiration` é separado do tempo imutável `CancelAfter` do canal.) Para mais informações, consulte o tipo de objeto de ledger PayChannel. | -### Error Cases +### Casos de Erro -Besides errors that can occur for all transactions, PaymentChannelFund transactions can result in the following transaction result codes: +Além dos erros que podem ocorrer em todas as transações, as transações PaymentChannelFund podem resultar nos seguintes códigos de resultado: -| Error Code | Description | +| Código de Erro | Descrição | | ------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `tecINSUFFICIENT_RESERVE` | The sending account has less XAH than the reserve requirement. | -| `tecNO_DST` | The destination account of the channel has been deleted. This is only possible if the payment channel was created before the fixPayChanRecipientOwnerDir amendment became enabled (on 2020-05-01). | -| `tecNO_ENTRY` | The Payment Channel identified by the `Channel` field does not exist. | -| `tecNO_PERMISSION` | The sender of the transaction is not the source address for the channel. | -| `tecUNFUNDED` | The sending account does not have enough Amount to fund the channel with the requested amount and still meet the reserve requirement. | -| `temBAD_AMOUNT` | The `Amount` field of the transaction is invalid. The amount cannot be zero or negative. | -| `temBAD_EXPIRATION` | The `Expiration` field is invalid. | +| `tecINSUFFICIENT_RESERVE` | A conta remetente possui menos XAH do que o requisito de reserva. | +| `tecNO_DST` | A conta de destino do canal foi excluída. Isso só é possível se o canal de pagamento foi criado antes da emenda fixPayChanRecipientOwnerDir entrar em vigor (em 2020-05-01). | +| `tecNO_ENTRY` | O Canal de Pagamento identificado pelo campo `Channel` não existe. | +| `tecNO_PERMISSION` | O remetente da transação não é o endereço de origem do canal. | +| `tecUNFUNDED` | A conta remetente não possui valor suficiente para financiar o canal com o montante solicitado e ainda atender ao requisito de reserva. | +| `temBAD_AMOUNT` | O campo `Amount` da transação é inválido. O valor não pode ser zero ou negativo. | +| `temBAD_EXPIRATION` | O campo `Expiration` é inválido. | diff --git a/src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-types/remit.mdx b/src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-types/remit.mdx new file mode 100644 index 0000000..ab91834 --- /dev/null +++ b/src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-types/remit.mdx @@ -0,0 +1,119 @@ +--- +title: Remit +description: >- + A transação Remit permite ao usuário enviar múltiplos tipos de pagamento, mintar um + URIToken, transferir uma lista de URITokens e ativar uma conta. +--- +import { Aside } from '@astrojs/starlight/components'; + + + +\[[Fonte](https://github.com/Xahau/xahaud/blob/dev/src/ripple/app/tx/impl/Remit.cpp)] + +_(Adicionado pela \[emenda Remit]\[].)_ + +### Exemplo + +```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" + } +} +``` + +| Campo | Tipo JSON | \[Tipo Interno]\[] | Descrição | +| ---------------- | --------- | ------------------ | ----------------------------------------------------------------------------------------------------------------------- | +| `Account` | String | AccountID | O endereço da conta que irá ativar a conta, enviar o pagamento e/ou mintar/transferir o(s) URIToken(s). | +| `Destination` | String | AccountID | O endereço único da conta que receberá o pagamento e/ou o(s) URIToken(s). | +| `DestinationTag` | Number | UInt32 | _(Opcional)_ Uma DestinationTag para depósitos em uma conta de custódia compartilhada. | +| `MintURIToken` | Object | STObject | _(Opcional)_ Um STObject `MintURIToken` contendo os detalhes do URIToken que deseja mintar no `Destination`. | +| `URITokenIDs` | Array | STArray | _(Opcional)_ Um array de URITokenIDs (hash de 256 bits) a serem transferidos para o `Destination`. _Limite de 32._ | +| `Amounts` | Array | STArray | _(Opcional)_ Um array de STObjects `AmountEntry` que a conta deseja enviar ao `Destination`. _Limite de 32._ | +| `Inform` | String | AccountID | _(Opcional)_ Endereço único de uma conta que pode ter um hook instalado e ser notificada quando uma remessa ocorrer. | +| `Blob` | String | Blob | _(Opcional)_ Valor hexadecimal arbitrário que pode ser adicionado à transação para uso em Hooks. | +| `InvoiceID` | String | Hash256 | _(Opcional)_ Hash de 256 bits arbitrário representando um motivo específico ou identificador para esta remessa. | + +### Campos de AmountEntry + +| Campo | Tipo JSON | \[Tipo Interno]\[] | Descrição | +| -------- | ---------------------------------------------------------------------------------------------------------------------------------- | ------------------ | ---------------------------------------------------------------------------- | +| `Amount` | [Valor de Moeda](/docs/protocol-reference/data-types/currency-formats/#specifying-currency-amounts) | Amount | O valor da moeda que a conta deseja enviar ao `Destination`. | + +### Campos de MintURIToken + +| Campo | Tipo JSON | \[Tipo Interno]\[] | Descrição | +| -------- | --------- | ------------------ | ------------------------------------------------------------------ | +| `URI` | String | String | A URI associada ao URIToken mintado. (máximo de 256 bytes) | +| `Digest` | String | Hash256 | _(Opcional)_ O digest do URIToken. | +| `Flags` | Number | UInt32 | _(Opcional)_ Flags na transação de mint. | + +### Flags de MintURIToken + +O STObject `MintURIToken` suporta os seguintes valores no campo `Flags`: + +| Nome da Flag | Valor Hex | Valor Decimal | Descrição | +| ------------ | ------------ | ------------- | ------------------------------------------------------------------------------------------------------ | +| `tfBurnable` | `0x00000001` | 1 | Permite ao emissor destruir o `URIToken` mintado. (O proprietário do `URIToken` _sempre_ pode fazê-lo.) | + +### Custo Especial de Transação + +A transação Remit possui um custo de transação padrão, que é a taxa mínima exigida para qualquer transação no Xahau. + +Além da taxa mínima exigida, a transação Remit também deduzirá as taxas para o seguinte: + +| Ação | Taxa | +| -------------------- | ---------------------------------- | +| `Account Activation` | Requisito de Reserva Padrão | +| `Create Trustline` | Requisito de Reserva Padrão | +| `URIToken Mint` | Requisito de Reserva Padrão | +| `URIToken Transfer` | Requisito de Reserva Padrão | + +### Casos de Erro + +Além dos erros que podem ocorrer em todas as transações, as transações Remit podem resultar nos seguintes códigos de resultado: + +| Código de Erro | Descrição | +| ------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `temINVALID_FLAG` | Ocorre se alguma flag especificar `tfFullyCanonicalSig`. | +| `temREDUNDANT` | Ocorre se a Account for igual ao Destination. | +| `temMALFORMED (Inform & Blob)` | Ocorre quando: sfInform é igual à origem ou ao destino. O Blob tinha mais de 128 KiB. | +| `temMALFORMED (AmountEntry)` | Ocorre quando: a contagem de AmountEntry excede `32`. AmountEntry esperado. A moeda nativa aparece mais de uma vez. A moeda emitida aparece mais de uma vez. | +| `temMALFORMED (MintURIToken)` | Ocorre quando: sfMintURIToken contém campo inválido. A URI não foi fornecida. A URI era muito longa/curta. UTF8 inválido dentro do MintURIToken. | +| `temMALFORMED (URITokenIDs)` | Ocorre quando: URITokenIDs muito curto/longo. URITokenID duplicado. | +| `temBAD_AMOUNT` | Ocorre quando um Amount no AmountEntry é inválido. | +| `terNO_ACCOUNT` | Ocorre quando a conta de origem não existe. | +| `tecNO_TARGET` | Ocorre quando o campo `sfInform` está presente, mas a conta não existe. | +| `tecNO_PERMISSION` | Ocorre quando `disallowIncomingRemit` está habilitado no `Destination`. | +| `tecNO_PERMISSION` | Ocorre quando o `Destination` possui `DepositAuthorization` habilitado. | +| `tecDST_TAG_NEEDED` | Ocorre se a conta de destino exige uma tag de destino, mas a transação não inclui uma. | +| `tecDUPLICATE` | Ocorre quando a URI do `MintURIToken` daquele emissor já existe. | +| `tecDIR_FULL` | Ocorre quando o diretório da conta de origem ou de destino está cheio. | +| `tecNO_ENTRY` | Ocorre quando o URIToken não existe. | +| `tecNO_PERMISSION` | Ocorre quando o URIToken não é de propriedade da conta de origem. | +| `tecUNFUNDED_PAYMENT` | Ocorre quando a conta de origem não possui os fundos necessários para executar a transação. (XAH ou Moedas Emitidas) | diff --git a/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/sethook.mdx b/src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-types/sethook.mdx similarity index 100% rename from src/content/docs/br/docs/protocol-reference/transactions/transaction-types/sethook.mdx rename to src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-types/sethook.mdx diff --git a/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/setregularkey.mdx b/src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-types/setregularkey.mdx similarity index 100% rename from src/content/docs/br/docs/protocol-reference/transactions/transaction-types/setregularkey.mdx rename to src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-types/setregularkey.mdx diff --git a/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/setremarks.mdx b/src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-types/setremarks.mdx similarity index 100% rename from src/content/docs/br/docs/protocol-reference/transactions/transaction-types/setremarks.mdx rename to src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-types/setremarks.mdx diff --git a/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/signerlistset.mdx b/src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-types/signerlistset.mdx similarity index 100% rename from src/content/docs/br/docs/protocol-reference/transactions/transaction-types/signerlistset.mdx rename to src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-types/signerlistset.mdx diff --git a/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/ticketcreate.mdx b/src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-types/ticketcreate.mdx similarity index 100% rename from src/content/docs/br/docs/protocol-reference/transactions/transaction-types/ticketcreate.mdx rename to src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-types/ticketcreate.mdx diff --git a/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/trustset.mdx b/src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-types/trustset.mdx similarity index 100% rename from src/content/docs/br/docs/protocol-reference/transactions/transaction-types/trustset.mdx rename to src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-types/trustset.mdx diff --git a/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/uritokenburn.mdx b/src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-types/uritokenburn.mdx similarity index 100% rename from src/content/docs/br/docs/protocol-reference/transactions/transaction-types/uritokenburn.mdx rename to src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-types/uritokenburn.mdx diff --git a/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/uritokenbuy.mdx b/src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-types/uritokenbuy.mdx similarity index 100% rename from src/content/docs/br/docs/protocol-reference/transactions/transaction-types/uritokenbuy.mdx rename to src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-types/uritokenbuy.mdx diff --git a/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/uritokencancelselloffer.mdx b/src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-types/uritokencancelselloffer.mdx similarity index 100% rename from src/content/docs/br/docs/protocol-reference/transactions/transaction-types/uritokencancelselloffer.mdx rename to src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-types/uritokencancelselloffer.mdx diff --git a/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/uritokencreateselloffer.mdx b/src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-types/uritokencreateselloffer.mdx similarity index 100% rename from src/content/docs/br/docs/protocol-reference/transactions/transaction-types/uritokencreateselloffer.mdx rename to src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-types/uritokencreateselloffer.mdx diff --git a/src/content/docs/br/docs/protocol-reference/transactions/transaction-types/uritokenmint.mdx b/src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-types/uritokenmint.mdx similarity index 100% rename from src/content/docs/br/docs/protocol-reference/transactions/transaction-types/uritokenmint.mdx rename to src/content/docs/pt-br/docs/protocol-reference/transactions/transaction-types/uritokenmint.mdx diff --git a/src/content/docs/br/docs/resources/media-kit.mdx b/src/content/docs/pt-br/docs/resources/media-kit.mdx similarity index 100% rename from src/content/docs/br/docs/resources/media-kit.mdx rename to src/content/docs/pt-br/docs/resources/media-kit.mdx diff --git a/src/content/docs/br/docs/resources/whitepaper.mdx b/src/content/docs/pt-br/docs/resources/whitepaper.mdx similarity index 100% rename from src/content/docs/br/docs/resources/whitepaper.mdx rename to src/content/docs/pt-br/docs/resources/whitepaper.mdx diff --git a/src/content/docs/br/docs/support/help-us.mdx b/src/content/docs/pt-br/docs/support/help-us.mdx similarity index 100% rename from src/content/docs/br/docs/support/help-us.mdx rename to src/content/docs/pt-br/docs/support/help-us.mdx diff --git a/src/content/docs/br/docs/what-is-different.mdx b/src/content/docs/pt-br/docs/what-is-different.mdx similarity index 80% rename from src/content/docs/br/docs/what-is-different.mdx rename to src/content/docs/pt-br/docs/what-is-different.mdx index 25a12d1..b002b75 100644 --- a/src/content/docs/br/docs/what-is-different.mdx +++ b/src/content/docs/pt-br/docs/what-is-different.mdx @@ -8,13 +8,13 @@ import { Aside, LinkCard } from '@astrojs/starlight/components'; O Xahau introduz o Escrow de Token IOU e os PayChannels como funcionalidades exclusivas, aumentando a flexibilidade e a segurança das transações. Eles facilitam a retenção temporária de tokens IOU sob condições predefinidas (escrow) e o estabelecimento de canais de pagamento para transações eficientes fora do ledger. - + #### URITokens, NÃO NFTokens Em vez de usar NFTokens como o XRPL, o Xahau emprega URITokens. Os URITokens são uma forma de ativos digitais não fungíveis com identificadores únicos e metadados, oferecendo uma abordagem inovadora para a representação de ativos na blockchain. - + #### Repositório Diferente @@ -26,13 +26,13 @@ O Xahau e o XRPL operam a partir de repositórios diferentes, o que indica que s O processo de build do Xahau incorpora WebAssembly (WASM) e a Máquina Virtual de Baixo Nível (LLVM), o que não está descrito no processo de build do XRPL. O Xahau utiliza essas tecnologias para aprimorar as capacidades de contratos inteligentes e melhorar o desempenho e a compatibilidade entre plataformas de sua base de código. - + #### Prazo de Amendment Diferente (5 dias) O processo de amendment no Xahau tem um prazo especificado de 5 dias, diferindo do cronograma do XRPL. Os amendments são mudanças de protocolo, e o período de 5 dias refere-se à duração que os validadores têm para chegar a um consenso e implementar essas mudanças. - + #### Sequência Inicial Diferente @@ -42,40 +42,40 @@ O Xahau emprega uma sequência inicial diferente para contas em relação ao XRP Importar do XRPL para o Xahau concede aos usuários 2 tokens XAH, indicando um mecanismo de incentivo para encorajar a migração de ativos ou a ponte do XRPL para o Xahau, potencialmente para aumentar a adoção da rede e a liquidez. - + #### Recompensas de Saldo (Recompensas por usar XAH) O Xahau oferece recompensas de saldo pela utilização do XAH, uma funcionalidade ausente no XRPL. Este é um sistema de recompensa por manter ou usar o token nativo do Xahau, XAH, para promover o engajamento e a estabilidade da rede. - + #### Hooks Os Hooks no Xahau, que não estão presentes no XRPL, são scripts programáveis ou funções semelhantes a contratos inteligentes que podem ser anexados a contas. Eles adicionam uma camada de programabilidade e automação às operações da rede. - + #### Estrutura de Governança A estrutura de governança do Xahau difere da do XRPL. O Xahau tem sua própria abordagem para tomada de decisões, sistemas de proposta ou papéis de validadores, o que pode influenciar a evolução da rede. - + #### Requisitos de Nó Executar um nó Xahau tem requisitos diferentes em comparação a um nó XRPL. Essas diferenças estão relacionadas às especificações técnicas necessárias para suportar as funcionalidades únicas e as demandas de rede do Xahau. - + #### Token Nativo O token nativo do Xahau é o XAH, distinto do XRP do XRPL. Como a moeda principal dentro da rede Xahau, o XAH serve como o principal meio de troca e reserva de valor, central para o quadro econômico da rede. - + #### Versionamento (Usa Datas) O Xahau emprega um sistema de versionamento baseado em datas, diferente da abordagem de versionamento do XRPL. Esse método pode fornecer uma maneira mais intuitiva de acompanhar as atualizações e o desenvolvimento histórico da rede. - + diff --git a/src/i18n/fraudReportTranslations.ts b/src/i18n/fraudReportTranslations.ts index 3adc198..740028d 100644 --- a/src/i18n/fraudReportTranslations.ts +++ b/src/i18n/fraudReportTranslations.ts @@ -1,4 +1,4 @@ -export type FraudReportLocale = 'en' | 'es' | 'ja' | 'br' +export type FraudReportLocale = 'en' | 'es' | 'ja' | 'pt-BR' export type FraudReportTranslations = { frontmatter: { @@ -371,7 +371,7 @@ export const fraudReportTranslations: Record< 'ネットワークエラー: サーバーに接続できませんでした。接続を確認して再度お試しください。', }, }, - 'br': { + 'pt-BR': { frontmatter: { title: 'Reportar Fraude', description: diff --git a/src/i18n/indexTranslations.ts b/src/i18n/indexTranslations.ts index 9600686..8ece552 100644 --- a/src/i18n/indexTranslations.ts +++ b/src/i18n/indexTranslations.ts @@ -102,7 +102,7 @@ export const indexTranslations = { stats_ledgers: '閉鎖済みレジャー', stats_node_cta: 'ノードを運営したいですか？', }, - 'br': { // Placeholder translations for Portuguese (Brazil) + 'pt-BR': { hero_title: 'A Blockchain Mais Inteligente com Programabilidade Baseada em Contas', hero_subtitle: 'Não apenas contratos inteligentes – contas inteligentes. Barato e rápido por design. Construído para o mundo real.', diff --git a/src/pages/br/about.mdx b/src/pages/br/about.mdx deleted file mode 100644 index 49c831f..0000000 --- a/src/pages/br/about.mdx +++ /dev/null @@ -1,57 +0,0 @@ ---- -title: Sobre Xahau -description: O que é Xahau? Uma explicação pequena ---- - -import PageLayout from "../../layouts/PageLayout.astro"; -import PageSection from "../../components/PageSection.astro"; - - - -
- -
- - -A Xahau é uma blockchain de camada 1 (L1) com uma combinação única de recursos e uma nova abordagem para programabilidade em blockchain, também conhecida como contratos inteligentes. - -A tecnologia, já comprovada ao longo do tempo, liquida transações em cerca de 4 segundos, com custos muito baixos — chegando a frações de centavo de dólar. É escalável, suportando atualmente até 10.000 transações por ledger, além de ser inerentemente sustentável e energeticamente eficiente. - -A Xahau oferece recursos nativos para emissão e negociação de moedas em sua exchange descentralizada integrada, NFTs nativos e diversas possibilidades para DeFi por meio de lógica personalizada com seus contratos inteligentes, chamados Hooks. - -Os Hooks ficam associados às contas, trazendo uma abordagem diferente para lógica customizada baseada em eventos de conta, como o recebimento de transações. Atualmente, Hooks são desenvolvidos em C, mas o suporte a JavaScript já foi desenvolvido e está em fase de testes, com outras linguagens também previstas. Isso torna os contratos inteligentes mais acessíveis para milhões de desenvolvedores, sem uma curva de aprendizado tão acentuada. - - - -### Qual é a tecnologia por trás da Xahau? - -A Xahau é uma evolução do código do XRP Ledger, aprimorada com contratos inteligentes, programabilidade baseada em contas (Hooks) e suporte igualitário para moedas emitidas em recursos nativos, como escrows e payment channels. - -Assim como a XRPL, a Xahau utiliza um mecanismo de consenso federado. As transações são confirmadas por um protocolo em que servidores independentes, chamados validadores, entram em consenso sobre a ordem e o resultado das transações. Todos os servidores processam cada transação segundo as mesmas regras, e qualquer transação válida é confirmada rapidamente. Todas as transações são públicas e transparentes, e qualquer pessoa pode operar um validador. - -A Xahau também introduz um modelo de governança comunitária para decisões da rede. Nesse sistema de duas camadas, os participantes votam em temas como assentos, Hooks e recompensas. - - - -## XAH: a moeda nativa da Xahau - -A moeda nativa da rede é o XAH, uma moeda inflacionária. Toda conta pode participar do ajuste de saldo ao interagir com um Hook na conta gênese, acumulando mensalmente 4% sobre o saldo. - -O XAH é usado para evitar spam na rede, adicionando um custo às transações. Transações comuns custam frações de XAH, enquanto interações com Hooks têm custo maior. O XAH também é necessário como reserva bloqueada para possuir contas, objetos ou armazenar dados consumidos por contratos inteligentes. - -Como os Hooks aumentam a taxa de queima de XAH em relação à XRPL, projetos que dependem dessa lógica customizada devem manter saldo suficiente para gerar ajuste mensal e cobrir taxas. - - - -## Principais eventos da Xahau - -A Xahau foi lançada em 30 de outubro de 2023 pela Xahau Launch Alliance, uma aliança temporária formada por desenvolvedores e organizações experientes do ecossistema XRPL: XRPL Labs, GateHub Limited, Titanium OU, Evernode Labs Ltd e Digital Governing OU. - -No primeiro ano, a rede recebeu várias atualizações, como o recurso nativo Remit (em março de 2024), melhorias de desempenho, nós que operam apenas em memória e suporte a Hooks em JavaScript. - -Também houve o lançamento de um serviço de remessas internacionais em parceria com a Inclusive Financial Technologies Foundation e o Cooperative Bank of Oromia, um dos maiores bancos da Etiópia. A solução permite que pessoas no exterior enviem valores em EUR digital via blockchain com liquidação quase instantânea e baixo custo para familiares na Etiópia em ETB. - -Além disso, a fundação firmou um memorando com a African Union para apoiar o Fundo da Paz da União Africana com uma plataforma de doações em múltiplas moedas baseada na Xahau. - - - diff --git a/src/pages/br/connect.mdx b/src/pages/br/connect.mdx deleted file mode 100644 index f07a0d0..0000000 --- a/src/pages/br/connect.mdx +++ /dev/null @@ -1,210 +0,0 @@ ---- -title: Xahau Connect -description: Eventos profissionais de blockchain para discussão séria e inovação ---- - -import PageLayout from "../../layouts/PageLayout.astro"; -import PageSection from "../../components/PageSection.astro"; - - - -## Próximos Eventos - -### Curso de Programação em Blockchain Non-EVM - -
-
- 📅 Data e Horário: Sexta-feira, 27 de fevereiro de 2026, às - 16h00 CET -
-
- 📍 Local: MIL (Madrid Innovation Lab) -
- Calle Bravo Murillo 37-39 -
- Madri, Espanha -
- - Ver no Google Maps - -
-
- 🎟️ Inscrição: Inscreva-se para participar presencialmente - por meio deste [formulário](https://luma.com/hiy3lsdq) -
-
- -Junte-se a nós para um curso introdutório gratuito sobre programação em blockchain Xahau, desenvolvido para ajudá-lo a dar seus primeiros passos nesse tipo de tecnologia. Este curso presencial de 4 horas foca no aprendizado de conceitos e ferramentas fundamentais por meio de exercícios práticos. Seja você um desenvolvedor curioso sobre alternativas Non-EVM, um empreendedor ou alguém sem experiência prévia em blockchain, o curso abordará tópicos desde arquitetura básica e criação de carteiras até contratos inteligentes em ambientes Non-EVM. Idioma: Espanhol e Inglês. - - - -## Eventos Anteriores - -### Custódia Institucional de Criptoativos e Tokenização de Ouro - -
-
- 📅 Data e Horário: Quarta-feira, 11 de fevereiro de 2026, - às 18h30 CET -
-
- 📍 Local: MIL (Madrid Innovation Lab) -
- Calle Bravo Murillo 37-39 -
- Madri, Espanha -
- - Ver no Google Maps - -
-
- 🎤 Palestrantes em Destaque: -
-
- • José Ángel Fernández – CEO, Prosegur Crypto -
-
-
-
- 📺 Sessão Gravada: Assista online no{" "} - - YouTube do Madrid Innovation Lab - -
-
- -Uma sessão presencial do Xahau Connect com José Ángel Fernández, CEO da Prosegur Crypto. A palestra explorou a jornada da Prosegur no ecossistema blockchain por meio da Prosegur Crypto, abordando a custódia institucional de criptoativos, como esses sistemas funcionam do ponto de vista tecnológico e de segurança, e os serviços oferecidos a clientes institucionais. A sessão também tratou da oferta de tokenização de ouro da Prosegur Crypto, discutindo tanto a implementação técnica quanto o modelo de negócio por trás da tokenização do ouro físico e seus casos de uso no mundo real. - -### Blockchain e Regulação: A Europa Sob Escrutínio Legal - -
-
- 📅 Data e Horário: Quinta-feira, 4 de dezembro de 2025, às - 18h30 CET -
-
- 📍 Local: MIL (Madrid Innovation Lab) -
- Calle Bravo Murillo 37-39 -
- Madri, Espanha -
- - Ver no Google Maps - -
-
- 🎤 Palestrantes em Destaque: -
-
- • Horacio Gómez Rey – Head of Legal Espanha, N26 -
-
- • Pedro Méndez de Vigo – AVP Legal Europa, Crypto.com -
-
-
-
- 📺 Sessão Gravada: Assista online no{" "} - - YouTube do Madrid Innovation Lab - -
-
- -Uma discussão aprofundada sobre regulação de blockchain na Europa, com especialistas jurídicos de destaque de grandes empresas de fintech e cripto. A sessão explorou o cenário regulatório em evolução, os desafios de conformidade e o futuro do blockchain sob o escrutínio legal europeu. - - - -## Sobre o Xahau Connect - -O **Xahau Connect** é uma série de eventos profissionais de blockchain criada pela [**INFTF**](https://www.inftf.org) (Inclusive Financial Technology Foundation) para fomentar discussões sérias e agnósticas sobre tecnologia blockchain e suas aplicações no mundo real. - -Os eventos reúnem especialistas, desenvolvedores profissionais, pesquisadores e inovadores de diversos ecossistemas blockchain para compartilhar conhecimento, explorar desafios e colaborar no avanço da tecnologia além do hype e da especulação. - -## Nossa Missão - -No Xahau Connect, focamos em: - -
-
- • Discussão Técnica Séria: Conversas aprofundadas sobre - arquitetura blockchain, negócios, oportunidades, regulação, inovação e muito - mais. -
-
- • Agnosticismo em Blockchain: Acolhendo perspectivas de - todos os ecossistemas e tecnologias blockchain. -
-
- • Networking Profissional: Conectando desenvolvedores, - especialistas, pesquisadores e líderes do setor. -
-
- • Aplicações no Mundo Real: Foco em implementações práticas - e casos de uso que impulsionam a adoção. -
-
- • Compartilhamento de Conhecimento: Aprendendo com - especialistas de diferentes domínios e setores da blockchain. -
-
- -## Quem Deve Participar - -Os eventos do Xahau Connect são voltados para: - -
-
• Desenvolvedores e Builders de Blockchain que trabalham em protocolos, contratos inteligentes, dApps e infraestrutura.
-
• Arquitetos Técnicos que projetam soluções e integrações em blockchain.
-
• Pesquisadores e Acadêmicos explorando teoria de blockchain, criptografia e sistemas distribuídos.
-
• Líderes Empresariais avaliando blockchain para aplicações de negócios.
-
• Contribuidores do Ecossistema que desenvolvem ferramentas, documentação e recursos comunitários.
-
• Profissionais do Setor aplicando blockchain em finanças, cadeia de suprimentos, identidade e outros setores. Se você leva a tecnologia e seu potencial a sério, o Xahau Connect é para você.
-
- - -## Palestrantes, Patrocinadores e Contato - -### Participe - -
-
- • Propostas de Palestra e Consultas sobre Patrocínio:{" "} - connect@xahau.org -
-
- -Somos gratos aos nossos parceiros que apoiam a missão do Xahau Connect de fomentar o discurso profissional sobre blockchain. Os detalhes de parceiros e palestrantes serão anunciados à medida que confirmamos a participação para os próximos eventos. - -### Inscreva-se para Atualizações - -Para receber notificações sobre os próximos eventos do Xahau Connect: - -
-
• Siga @XahauNetwork e INFTF no X
-
• Envie um e-mail para connect@xahau.org
-
- - diff --git a/src/pages/br/contest.mdx b/src/pages/br/contest.mdx deleted file mode 100644 index ed566cc..0000000 --- a/src/pages/br/contest.mdx +++ /dev/null @@ -1,251 +0,0 @@ ---- -title: Xahau Dev Contest -description: Ecosystem Rising - Construa serviços voltados ao usuário com a Xahau ---- - -import PageLayout from "../../layouts/PageLayout.astro"; -import PageSection from "../../components/PageSection.astro"; - - - -## Introdução - -Bem-vindo ao **Xahau Dev Contest: Ecosystem Rising**! -Este concurso convida inovadores a construírem **serviços voltados ao usuário com a Xahau** e a competirem por prêmios enquanto fortalecem o ecossistema Xahau. - -## Prêmios - -- **3 prêmios principais em XAH** para os projetos vencedores. - - **🥇 1º Lugar** valor de 4000 USD em XAH. - - **🥈 2º Lugar** valor de 2000 USD em XAH. - - **🥉 3º Lugar** valor de 1000 USD em XAH. - -## Cronograma - -- **Prazo de submissão:** 1º de fevereiro de 2026. -- **Painel de juízes:** 5 membros da comunidade Xahau e XRPL (veja abaixo). - - - - -## Painel de Juízes - -O concurso será avaliado por **cinco membros da comunidade**: - -- • [**tequ**](https://x.com/_tequ_) – Desenvolvedor Blockchain Xahau -- • [**Robert Kiuru**](https://x.com/robertkiuru) – COO, _XRPL Labs_ -- • **[gadget78](https://x.com/gadget78)** – Desenvolvedor Evernode -- • [**Andrei Rosseti**](https://x.com/andreirosseti) – Arquiteto do Xahau DocProof | CTO, _EleveCRM_ -- • [**Vet**](https://x.com/Vet_X0) – Contribuidor da Comunidade XRPL - -## Tema: Serviços na Xahau - -Os participantes devem construir **serviços baseados na web que interajam com a Xahau (Mainnet)** e sejam projetados para o **usuário final**, seja usuários casuais, usuários avançados, setor público ou setor privado. - -Exemplos incluem **(mas não se limitam a)**: - -
-
- • Ferramentas para o usuário cotidiano: -
-
◦ Painéis de finanças pessoais
-
◦ Gerenciadores de carteiras
-
◦ Aplicativos comunitários
-
-
-
- • Serviços empresariais: -
-
◦ Portais de pagamento
-
◦ Plataformas de fidelidade
-
◦ Ferramentas de atendimento ao cliente
-
-
-
- • Plataformas públicas: -
-
◦ Marketplaces de NFT
-
◦ Sistemas de votação
-
◦ Hubs de doação
-
◦ Aplicativos culturais
-
◦ Utilitários para o bem social
-
-
-
- - -## Regras de Participação - -
-
• Você pode submeter quantos projetos quiser.
-
• Cada projeto pode ser submetido por um indivíduo ou um grupo de participantes.
-
• Projetos diferentes do(s) mesmo(s) participante(s) podem ser elegíveis para prêmios diferentes.
-
• Os projetos devem funcionar na Xahau Mainnet.
-
-
• Cada projeto deve estar acessível online, para que tanto os juízes quanto o público possam usá-lo ou visualizá-lo.
-
◦ Isso evita que os juízes precisem instalar ou configurar os projetos localmente, e reduz o risco de erros inesperados ou a necessidade de assistência do participante.
-
-
-
• Cada submissão deve incluir documentação básica para ajudar outros a entenderem o projeto.
-
◦ Opcionalmente, você também pode incluir material multimídia (vídeos, slides, demos, etc.) para explicar melhor seu trabalho.
-
-
• Ferramentas de IA podem ser usadas tanto para desenvolvimento quanto para documentação.
-
• Se o seu projeto usar Hooks, o código do Hook deve ser de código aberto, para que possa ser auditado por segurança e servir como recurso de aprendizado para a comunidade. Você deve anexar o código C na sua submissão juntamente com o hash do hook. Consulte a seção "Formato de Submissão".
-
• Projetos que claramente oferecem serviços financeiros regulados ou que visam atividades ilegais não são elegíveis.
-
• Para ser avaliado pelos juízes, você deve incluir sua submissão com um PR conforme indicado na seção "Formato de Submissão".
-
• Após a criação do seu PR de submissão, publique um tweet no X sobre seu projeto, marcando @XahauNetwork, para anunciar sua participação no Xahau Dev Contest.
-
- - -## Critérios de Avaliação - -Ao revisar as submissões, os juízes valorizarão especialmente: - -
-
• Originalidade e criatividade da ideia.
-
• Ausência de concorrentes existentes oferecendo o mesmo serviço na Xahau Mainnet antes do concurso.
-
• Impacto e utilidade para os usuários finais (indivíduos, empresas ou setor público).
-
• Qualidade de execução (estabilidade, documentação, experiência do usuário).
-
• Uso de Hooks (Contratos Inteligentes na Xahau).
-
- - -## Formato de Submissão - -Cada projeto deve incluir uma pasta e pelo menos um **arquivo de submissão** dentro do diretório de submissões do **[repositório](https://github.com/xahau/xahau-2nd-dev-contest)**. -O arquivo e o diretório devem ter o nome do seu usuário do GitHub seguido do nome do projeto, separados por um underscore, usando a extensão .md para o arquivo. - -Exemplo: submissions/NomeGitHub_NomeProjeto/NomeGitHub_NomeProjeto.md - -O arquivo deve conter os seguintes campos: - -
-
- • Título do Projeto -
-
- • Breve Descrição -
-
- • Participantes (nomes ou apelidos) -
-
- • Redes Sociais dos Participantes -
-
- • E-mail de Contato -
-
- • Link para o Projeto Online -
-
- • Endereço Xahau para receber o prêmio em caso de vitória -
-
- • Link para a Documentação -
-
- • Código dos Hooks em C e hash correspondente (caso seu - projeto use um ou mais, para confirmar que é seguro, adicione os arquivos .c - na pasta da sua submissão) -
-
- • Conta Hooks do projeto (para confirmar que você está - usando os hooks previamente fornecidos para este projeto) -
-
- • Link para o Repositório do Projeto (opcional) -
-
- • Outros Links (opcional, ex.: vídeo demo, apresentação, - slides) -
-
- -Um diretório e arquivo de modelo estão disponíveis na pasta do repositório, que os participantes podem usar para preencher os detalhes do seu projeto. - - - -## Suporte e Comunidade - -Se tiver dúvidas ou precisar de orientação: - -- Entre no **[Discord dos Xahau Builders](https://discord.gg/ds7nb93mYj)**. -- Ou envie um e-mail para **[contests@xahau.org](mailto:contests@xahau.org)**. - -Tentaremos responder o mais rápido possível. Suas perguntas também podem ser adicionadas ao FAQ neste README para que outros se beneficiem das respostas. - -## Propriedade - -- Todos os projetos submetidos permanecem **propriedade de seus criadores originais**. - -## Links Úteis - -Aqui estão alguns recursos úteis para desenvolvedores Xahau: - -- [Documentação Xahau](https://docs.xahau.network) -- [Documentação de Hooks Xahau](https://xahau.network/docs/hooks/) -- [Repositórios GitHub da Xahau](https://github.com/Xahau) -- [Website Xaman](https://xaman.app) -- [Faucet da Testnet Xahau](https://xahau-test.net/) -- [Discord Xahau](https://discord.gg/ds7nb93mYj) - -## Resumo: O Que Você Precisa Fazer - -
-
• Inspire-se. Seja criativo e motivado para construir algo que fortaleça o ecossistema Xahau.
-
• Construa seu projeto. Desenvolva seu serviço baseado na web usando a Xahau Mainnet.
-
• Submeta seu trabalho. Crie um PR (Pull Request) seguindo as instruções na seção "Formato de Submissão".
-
• Anuncie sua participação. Publique um tweet no X sobre seu projeto, marcando @XahauNetwork, e compartilhe que você participou do Xahau Dev Contest.
-
- - -## FAQ - -**P: Posso submeter mais de um projeto?** - -- R: Sim! Você pode submeter quantos quiser, individualmente ou em grupo. - -**P: Os projetos precisam ser de código aberto?** - -- R: Não, mas devem incluir pelo menos documentação básica para que os juízes entendam como funcionam. Se o seu projeto incluir Hooks, você deve anexar o código C na sua submissão junto com o hash do hook. Consulte a seção "Formato de Submissão". - -**P: Posso usar IA para me ajudar a construir ou documentar meu projeto?** - -- R: Sim, o uso de IA é totalmente permitido. - -**P: Que tipo de serviços vocês esperam?** - -- R: Qualquer serviço que ofereça **valor aos usuários finais** — sejam indivíduos, empresas ou o setor público. Desde marketplaces de NFT e painéis financeiros até sistemas de votação, aplicativos de pagamento, hubs de doação ou qualquer serviço inovador público/privado. - -**P: Há vantagem em usar Hooks?** - -- R: Sim, projetos que implementam criativamente **Hooks (contratos inteligentes na Xahau)** receberão reconhecimento especial. - -**P: O que acontece com meu projeto após o concurso?** - -- R: Você mantém a propriedade total. - -**P: Onde posso fazer perguntas?** - -- R: No **[Discord da Comunidade Xahau](https://discord.gg/ds7nb93mYj)** ou enviando um e-mail para **[contests@xahau.org](mailto:contests@xahau.org)**. - - - - -## Aviso Final - -Ao participar, você concorda com o seguinte: - -
-
• Os participantes devem atender aos critérios de elegibilidade e seguir todas as regras. Não é permitido submeter projetos que já foram publicados antes da competição.
-
• Os projetos permanecem propriedade de seus criadores, mas os organizadores reservam o direito de exibir, compartilhar ou destacar as submissões com o devido crédito.
-
• Os organizadores reservam o direito de desqualificar submissões que violem as regras ou comprometam a integridade do concurso. Todas as decisões do júri são finais e não estão sujeitas a recurso.
-
• Os organizadores não são responsáveis por danos, despesas ou perdas durante a participação. Os organizadores também reservam o direito de modificar os requisitos do concurso a qualquer momento, se necessário.
-
• Você reconhece que sanções e certas restrições jurisdicionais podem se aplicar. A elegibilidade para receber recompensas pode exigir conformidade com as leis aplicáveis, incluindo a conclusão da verificação KYC (Conheça Seu Cliente).
-
• Todos os impostos, taxas ou outras obrigações financeiras relacionadas às recompensas são de responsabilidade exclusiva dos participantes.
-
• Se tiver dúvidas ou incertezas sobre elegibilidade, requisitos ou obrigações fiscais, entre em contato conosco pelos canais de comunicação fornecidos antes de submeter sua inscrição.
-
Agora é sua vez: **Construa, submeta e mostre sua inovação com a blockchain Xahau!**
-
- - diff --git a/src/pages/br/ecosystem.mdx b/src/pages/br/ecosystem.mdx deleted file mode 100644 index a892a50..0000000 --- a/src/pages/br/ecosystem.mdx +++ /dev/null @@ -1,172 +0,0 @@ ---- -layout: ../../layouts/PageLayout.astro -title: Ecossistema -description: Xahau ao redor do mundo ---- - -import EcosystemButton from "../../components/EcosystemButton.astro"; -import gatehub from "../../assets/ecosystem-logos/gatehub.png"; -import bitrue from "../../assets/ecosystem-logos/bitrue.png"; -import bithomp from "../../assets/ecosystem-logos/bithomp.png"; -import xahscan from "../../assets/ecosystem-logos/xahscan.png"; -import xahau_services from "../../assets/ecosystem-logos/xahau-services.png"; -import xrplwin from "../../assets/ecosystem-logos/xrplwin.png"; -import xaman from "../../assets/ecosystem-logos/xaman.png"; -import dcent from "../../assets/ecosystem-logos/dcent.png"; -import bitmart from "../../assets/ecosystem-logos/bitmart.png"; -import coinex from "../../assets/ecosystem-logos/coinex.png"; - -## Carteiras - -
- - - - -
- -## Corretoras - -
- - - - -
- -## Exploradores e utilitários - -
- - - - -
- -## Projetos - -
- - - - - - - - - - - - - - - - - - -
diff --git a/src/pages/br/features.mdx b/src/pages/br/features.mdx deleted file mode 100644 index 41e3a9b..0000000 --- a/src/pages/br/features.mdx +++ /dev/null @@ -1,96 +0,0 @@ ---- -title: Recursos -description: Tecnologia comprovada com uma abordagem inovadora ---- - -import PageLayout from "../../layouts/PageLayout.astro"; -import PageSection from "../../components/PageSection.astro"; - - - -## Hooks: Lógica de Contrato Inteligente no Nível da Conta - -A 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 incorporados diretamente nas contas dos usuários. Esses Hooks podem automaticamente inspecionar, modificar ou rejeitar qualquer transação envolvendo aquela conta, sem necessidade de chamadas de função explícitas. - -Por serem executados de forma inline e dentro do consenso, os Hooks oferecem programabilidade em tempo real com sobrecarga mínima. 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 das transações. - -## Controle de Tokens e Ativos por Design - -A Xahau oferece a emissores e usuários **controle granular sobre tokens e trustlines**. Funcionalidades como `TrustSet`, `Clawback`, `Freeze` e `Deposit Authorization` permitem personalização total de como os tokens podem ser usados ou recebidos. Ativos podem ser permitidos, bloqueados ou queimados, tudo aplicado no nível do protocolo. - -Isso torna a Xahau excepcionalmente adequada para instrumentos financeiros regulados, stablecoins, programas de fidelidade ou cadeias de suprimento corporativas — qualquer cenário onde conformidade, segurança e precisão são essenciais. - - - -## Governance Game: Coordenação Descentralizada com Propósito - -A Xahau conta com um sistema de governança inovador sustentado pelo **Governance Game**, um mecanismo transparente e on-ledger para propor, revisar e votar em emendas. Os operadores de validadores (Governadores) participam diretamente na moldagem do protocolo, enquanto competem em um sistema estruturado de recompensas baseado em responsabilidade e engajamento. - -Esse 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 transformar a governança em um jogo seguro e alinhado a incentivos, a Xahau estabelece um novo padrão para coordenação on-chain. - -## Balance Rewards: Rendimento Passivo Sem Staking - -A Xahau oferece um sistema de **Balance Rewards** que permite às contas acumular valor passivamente apenas por manterem ativos. Essas recompensas são calculadas com base no saldo da conta e distribuídas por um mecanismo garantido pelo consenso, sem exigir staking, delegação ou contratos de terceiros. - -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 de sistemas de yield farming ou staking em outras blockchains, o modelo de recompensas da Xahau não exige que os usuários bloqueiem ativos ou persigam estratégias complexas de DeFi — funciona nativamente, com transparência e simplicidade. - - - -## Escrow: Transferências Condicionais para Qualquer Ativo - -A Xahau suporta **escrow on-ledger** de tokens nativos e **emitidos**, possibilitando 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 em condições, aplicada pela própria rede. - -Seja construindo um sistema de pagamento baseado em marcos, liquidação em marketplace ou distribuição confiável de tokens, os escrows da Xahau oferecem uma ferramenta simples e poderosa — sem necessidade de contratos inteligentes externos. O suporte nativo tanto para ativos fungíveis quanto não fungíveis em escrow torna esse um recurso excepcionalmente versátil. - -## Remit: Transferências Nativas Entre Contas - -O recurso **Remit** permite transações simplificadas e com múltiplas operações 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 mudanças de saldo de forma atômica. - -Isso melhora a eficiência e a confiabilidade, especialmente para processadores de pagamento, marketplaces ou aplicações que precisam realizar operações agrupadas. Por estar integrado ao protocolo, o Remit garante desempenho previsível, baixa latência e forte auditabilidade. - - - -## Taxas Baixas com Queima de Taxas - -A 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 da rede a longo prazo. 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. - -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 no estilo de leilão, a Xahau oferece previsibilidade e alinhamento econômico para todos os usuários. - -## Rápida, Verde e Escalável - -Construída sobre uma versão aprimorada do protocolo de consenso do XRPL, a 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 servir casos de uso financeiros e empresariais do mundo real sem comprometer o meio ambiente ou a experiência do usuário. - -A arquitetura da 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. - - - -## URITokens: NFTs Nativos na Xahau - -Os **URITokens** representam a abordagem da Xahau para tokens não fungíveis (NFTs), implementados como parte nativa do ledger em vez de via contratos inteligentes separados. Um URIToken é um objeto de primeira classe no ledger, identificado exclusivamente pela conta emissora e por um Identificador Uniforme de Recursos (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. - -Esse padrão NFT integrado significa que criadores podem mintar, negociar ou queimar 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, oferecendo flexibilidade no gerenciamento de NFTs. Ao integrar NFTs no nível do protocolo, a Xahau torna a emissão e o gerenciamento de colecionáveis digitais ou credenciais mais eficientes e seguros. - -## Offers: Exchange Descentralizada (DEX) Integrada - -A Xahau inclui um sistema nativo de **Offers**, que alimenta uma exchange descentralizada integrada no 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. - -Esse recurso, herdado do DEX do XRPL, permite um ambiente de negociação dinâmico e responsivo onde a troca de valor acontece ponto a ponto sem exchanges intermediárias. A capacidade de colocar e cancelar ordens de negociação é fornecida por transações dedicadas (OfferCreate e OfferCancel). Ao contrário de muitas blockchains que exigem contratos inteligentes ou plataformas externas para negociação, o DEX da Xahau é um recurso de primeira classe do ledger. Essa exchange on-ledger oferece liquidação rápida e taxas baixas, tornando a negociação de ativos transparente para usuários e aplicações. - - - -## Checks: Sistema de Pagamento Diferido - -A Xahau suporta **Checks**, um sistema de pagamento diferido semelhante a escrever cheques digitais na blockchain. Uma parte pode emitir um Check (promessa de pagamento) que o destinatário pretendido pode sacar em um momento posterior 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á reivindicar quando determinadas condições forem atendidas. - -O ledger possui transações dedicadas para criar um cheque, sacá-lo ou cancelá-lo. Poucas outras plataformas têm esse tipo de instrumento de pagamento diferido nativo; o sistema de cheques da Xahau fornece uma camada extra de controle de pagamento, tudo aplicado pelas regras da rede sem necessidade de contratos inteligentes personalizados. - -## Payments: Transferências Multi-Ativo e Canais - -A funcionalidade de **Payments** na Xahau foi projetada para facilitar transferências de valor rápidas e flexíveis em toda a rede. De forma única, a Xahau (assim como o XRPL) suporta _pagamentos multi-ativo_ por meio de um sistema de trust lines e moedas emitidas. Usando uma transação `TrustSet`, duas partes podem estabelecer uma trust line para transacionar em um ativo personalizado ou IOU, permitindo suporte integrado a múltiplas moedas ou tokens sem necessidade de contratos inteligentes. - -Isso significa que empresas podem emitir stablecoins ou tokens na Xahau e os usuários podem enviá-los ou trocá-los nativamente. O conjunto de Payments também inclui recursos avançados como **Deposit Preauthorization**, que permite a uma conta criar uma lista de permissões de quem pode lhe enviar fundos, adicionando segurança contra transações indesejadas. - -Além disso, a 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 então liquidem o resultado líquido na blockchain. Com transações como PaymentChannelCreate, Fund e Claim, a Xahau viabiliza micropagamentos ou pagamentos em streaming que são garantidos pelo ledger sem congestioná-lo. - - - diff --git a/src/pages/br/roadmap.mdx b/src/pages/br/roadmap.mdx deleted file mode 100644 index 71f2eb0..0000000 --- a/src/pages/br/roadmap.mdx +++ /dev/null @@ -1,70 +0,0 @@ ---- -title: Roadmap -description: Este ano, a Xahau Network pretende receber atualizações poderosas em escalabilidade, acessibilidade, segurança e inovação ---- - -import PageLayout from "../../layouts/PageLayout.astro"; -import PageSection from "../../components/PageSection.astro"; -import roadmap from "../../assets/roadmap_2025.jpeg"; -import { Image } from "astro:assets"; - - - -Xahau roadmap 2025 - -# 1º Semestre de 2025 - -## 1. Projeto "L10K" - -Melhorar a eficiência da tecnologia central para aumentar a capacidade de transações para 10.000 transações por ledger, com mais eficiência e segurança. - -Um marco de desempenho para o ecossistema Xahau! - -## 2. Melhoria do Monitoramento UDP e RPC - -Recursos de monitoramento sem conexão e RPC para operadores de nós otimizam o desempenho e a escalabilidade em toda a rede. - -Permitindo monitoramento eficiente e passivo de ambientes com um ou múltiplos nós — reduzindo significativamente a sobrecarga. - -## 3. Finalização de Novos Recursos (Remarks, Touch, Blackhole, DataMonitor) - -Concluir o desenvolvimento e a integração desses recursos de ponta, melhorando a interação com a Xahau tanto para desenvolvedores quanto para usuários finais por meio de produtos criados pelos desenvolvedores. - -## 4. Suporte Completo à Hardware Wallet Ledger para Xahau - -Garantir transações seguras e simplificadas na Xahau com compatibilidade com a Hardware Wallet Ledger, ampliando a acessibilidade à Xahau em todo o mundo. - -## 5. Acesso a Exchanges e Plataformas On/Off-Ramp - -A Xahau pretende se tornar mais acessível por meio de exchanges e plataformas on/off-ramp, apoiando uma participação e integração mais amplas no ecossistema. - -## 6. Suporte ao LedgerLive - -Integração da Xahau com o Ledger Live, permitindo fácil acesso e gerenciamento usando o popular produto Ledger Live. - -## 7. Frame Universal Embeddable de Explicação de Hooks - -Permitindo que qualquer carteira integre facilmente uma explicação clara da influência dos Hooks nas transações (web, mobile, desktop), com visuais claros e integrados para transações HookSet, garantindo uma adoção mais fácil. - -# 2º Semestre de 2025 - -## 8. Implementação de Hooks em JavaScript - -Pendente de aprovação de auditoria, levar Hooks baseados em JavaScript e suas ferramentas a dezenas de milhões de desenvolvedores ao redor do mundo para desenvolver usando a Xahau para lógica on-chain avançada e capacidades de transações programáveis. - -## 9. Auditorias Abrangentes e Verificações de Segurança - -Concluir auditorias de todos os principais recursos de 2025 para demonstrar a segurança e a estabilidade da rede, oferecendo garantias verificáveis ao mundo à medida que avançamos para 2026. - -## 10. Melhoria da Experiência do Usuário - -Orientado por feedback, o ecossistema Xahau garantirá integração e usabilidade perfeitas em todas as carteiras e aplicações. - -## 11. Implementação de Batch - -Viabilizar verificações eficientes de múltiplas transações, garantindo que todas ou nenhuma das transações ocorram, enquanto permite que provedores de serviços incorporem operações específicas de fluxo de trabalho de forma transparente no fluxo de transações. - -**2025 é o ano em que a Xahau se torna mais fácil de acessar, usar, aproveitar e construir, enquanto escala de forma mais inteligente, rápida e robusta.** - - - diff --git a/src/pages/pt-br/about.astro b/src/pages/pt-br/about.astro new file mode 100644 index 0000000..e5421d3 --- /dev/null +++ b/src/pages/pt-br/about.astro @@ -0,0 +1,16 @@ +--- +import '../../styles/main.css' +import XahauAbout from '../../components/XahauAboutPtBR.astro' +import BaseLayout from '../../layouts/BaseLayout.astro' + +const _frontmatter = { + title: 'Sobre Xahau', + description: 'Enterprise L1 blockchain with account-based programmability', +} +--- + + +
+ +
+ diff --git a/src/pages/pt-br/connect.astro b/src/pages/pt-br/connect.astro new file mode 100644 index 0000000..5552ccc --- /dev/null +++ b/src/pages/pt-br/connect.astro @@ -0,0 +1,17 @@ +--- +import '../../styles/main.css' +import XahauConnect from '../../components/XahauConnect.astro' +import BaseLayout from '../../layouts/BaseLayout.astro' + +const _frontmatter = { + title: 'Xahau Connect', + description: + 'Eventos profissionais de blockchain para discussões sérias e inovação.', +} +--- + + +
+ +
+ diff --git a/src/pages/pt-br/contest.astro b/src/pages/pt-br/contest.astro new file mode 100644 index 0000000..75f2e78 --- /dev/null +++ b/src/pages/pt-br/contest.astro @@ -0,0 +1,16 @@ +--- +import '../styles/main.css' +import XahauContest from '../components/XahauContest.astro' +import BaseLayout from '../layouts/BaseLayout.astro' + +const _frontmatter = { + title: 'Xahau Dev Contest', + description: 'Ecosystem Rising — Build user-facing services powered by Xahau', +} +--- + + +
+ +
+ diff --git a/src/pages/pt-br/ecosystem.astro b/src/pages/pt-br/ecosystem.astro new file mode 100644 index 0000000..4bbda86 --- /dev/null +++ b/src/pages/pt-br/ecosystem.astro @@ -0,0 +1,16 @@ +--- +import '../../styles/main.css' +import XahauEcosystem from '../../components/XahauEcosystem.astro' +import BaseLayout from '../../layouts/BaseLayout.astro' + +const _frontmatter = { + title: 'Ecosystem', + description: 'Xahau around the world', +} +--- + + +
+ +
+ diff --git a/src/pages/pt-br/features.astro b/src/pages/pt-br/features.astro new file mode 100644 index 0000000..eccdd59 --- /dev/null +++ b/src/pages/pt-br/features.astro @@ -0,0 +1,16 @@ +--- +import '../../styles/main.css' +import XahauFeatures from '../../components/XahauFeaturesPtBR.astro' +import BaseLayout from '../../layouts/BaseLayout.astro' + +const _frontmatter = { + title: 'Funcionalidades', + description: 'Tecnologia comprovada com uma abordagem inovadora', +} +--- + + +
+ +
+ diff --git a/src/pages/br/fraud-report.astro b/src/pages/pt-br/fraud-report.astro similarity index 100% rename from src/pages/br/fraud-report.astro rename to src/pages/pt-br/fraud-report.astro diff --git a/src/pages/br/index.mdx b/src/pages/pt-br/index.mdx similarity index 100% rename from src/pages/br/index.mdx rename to src/pages/pt-br/index.mdx diff --git a/src/pages/br/privacy-policy.mdx b/src/pages/pt-br/privacy-policy.mdx similarity index 100% rename from src/pages/br/privacy-policy.mdx rename to src/pages/pt-br/privacy-policy.mdx diff --git a/src/pages/pt-br/roadmap.astro b/src/pages/pt-br/roadmap.astro new file mode 100644 index 0000000..3c8d2dd --- /dev/null +++ b/src/pages/pt-br/roadmap.astro @@ -0,0 +1,16 @@ +--- +import '../../styles/main.css' +import XahauRoadmap from '../../components/XahauRoadmap.astro' +import BaseLayout from '../../layouts/BaseLayout.astro' + +const _frontmatter = { + title: 'Roadmap', + description: 'Xahau roadmap across the upcoming quarters', +} +--- + + +
+ +
+ diff --git a/src/plugins/remarkGlobalReferences.ts b/src/plugins/remarkGlobalReferences.ts index 38e0e39..c1737c6 100644 --- a/src/plugins/remarkGlobalReferences.ts +++ b/src/plugins/remarkGlobalReferences.ts @@ -82,7 +82,7 @@ export function remarkGlobalReferences() { } } - const NON_ROOT_LOCALES = ['es', 'ja', 'br'] + const NON_ROOT_LOCALES = ['es', 'ja', 'pt-BR'] return function transformer(tree: any, vfile: any) { const refs = loadGlobalReferences() diff --git a/src/utils/localizedHref.ts b/src/utils/localizedHref.ts index fc18a4b..a7a2655 100644 --- a/src/utils/localizedHref.ts +++ b/src/utils/localizedHref.ts @@ -17,7 +17,7 @@ function splitPath(path: string) { export function stripLocalePrefix(pathname: string) { const normalizedPathname = normalizePathname(pathname) - for (const locale of ['es', 'ja'] as const) { + for (const locale of ['es', 'ja', 'pt-br'] as const) { if (normalizedPathname === `/${locale}`) return '/' if (normalizedPathname.startsWith(`/${locale}/`)) { return normalizePathname(normalizedPathname.slice(locale.length + 1)) From 03d43326e345a881c11105f6ca96f9e529afdf73 Mon Sep 17 00:00:00 2001 From: Andrei Rosseti Date: Tue, 21 Apr 2026 21:24:58 -0300 Subject: [PATCH 03/20] fix: general adjusts --- src/components/Footer.astro | 2 +- src/components/Header.jsx | 2 +- src/components/XahauConnect.astro | 3 +- src/components/XahauEcosystem.astro | 21 ++- src/data/ecosystem.json | 50 +++++-- src/data/roadmap.json | 212 +++++++++++++++++++--------- src/pages/pt-br/ecosystem.astro | 2 +- src/pages/pt-br/roadmap.astro | 6 +- src/pages/roadmap.astro | 2 +- 9 files changed, 205 insertions(+), 95 deletions(-) diff --git a/src/components/Footer.astro b/src/components/Footer.astro index a7ef3bd..7d90b92 100644 --- a/src/components/Footer.astro +++ b/src/components/Footer.astro @@ -66,7 +66,7 @@ const translations = { discord: 'コミュニティDiscord', copyright: `© ${new Date().getFullYear()} Xahau. オープンソース`, }, - 'br': { + 'pt-BR': { tagline: 'Este site é open source e está aberto a contribuições', on: 'em', about: 'Sobre', diff --git a/src/components/Header.jsx b/src/components/Header.jsx index 206b2fd..155517b 100644 --- a/src/components/Header.jsx +++ b/src/components/Header.jsx @@ -62,7 +62,7 @@ const nav = { about: 'Sobre', features: 'Recursos', ecosystem: 'Ecossistema', - roadmap: 'Roteiro', + roadmap: 'Roadmap', docs: 'Documentação', connect: 'Conectar', explorers: 'Exploradores', diff --git a/src/components/XahauConnect.astro b/src/components/XahauConnect.astro index e7b5996..b773a09 100644 --- a/src/components/XahauConnect.astro +++ b/src/components/XahauConnect.astro @@ -12,10 +12,9 @@ */ import connectData from '../data/connect.json' -import { normalizeLocale } from '../utils/localizedHref' type Locale = 'en' | 'es' | 'ja' | 'pt-BR' -const locale = normalizeLocale(Astro.currentLocale ?? 'en') as Locale +const locale = (Astro.currentLocale ?? 'en') as Locale // ── Date-based split (build time) ──────────────────────────────────────────── const today = new Date() diff --git a/src/components/XahauEcosystem.astro b/src/components/XahauEcosystem.astro index d68022c..886d9f3 100644 --- a/src/components/XahauEcosystem.astro +++ b/src/components/XahauEcosystem.astro @@ -45,9 +45,12 @@ const logoMap: Record = { quantoz: logoQuantoz, } -type Locale = 'en' | 'es' | 'ja' | 'pt-br' +type Locale = 'en' | 'es' | 'ja' | 'pt-BR' const locale = (Astro.currentLocale ?? 'en') as Locale +const meta = ecosystemData.meta +const L = (rec: Record) => rec[locale] ?? rec['en'] ?? Object.values(rec)[0] + // Projects sorted alphabetically at build time; others keep editorial order. const sections = ecosystemData.sections.map((section) => section.id === 'projects' @@ -63,15 +66,15 @@ const sections = ecosystemData.sections.map((section) =>
-

Ecosystem

+

{L(meta.title)}

- {sections.map(s => s.label['en']).join(', ')} - built on or around Xahau + {sections.map(s => L(s.label)).join(', ')} + {L(meta.subtitle_suffix)}

{sections.map(s => ( - {s.items.length} {s.label['en']} + {s.items.length} {L(s.label)} ))}
@@ -158,13 +161,7 @@ const sections = ecosystemData.sections.map((section) => ) })} -

- {locale === 'es' - ? 'Todas las marcas y logotipos son propiedad de sus respectivos dueños.' - : locale === 'ja' - ? 'すべての商標およびロゴは、各所有者の財産です。' - : 'All trademarks and logos are the property of their respective owners.'} -

+

{L(meta.trademark)}

diff --git a/src/components/XahauFeaturesPtBR.astro b/src/components/XahauFeaturesPtBR.astro deleted file mode 100644 index b454ccb..0000000 --- a/src/components/XahauFeaturesPtBR.astro +++ /dev/null @@ -1,745 +0,0 @@ ---- -/** - * 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 ---- - -
- -
-
-

Funcionalidades

-

Tecnologia comprovada com uma abordagem inovadora

-
-
- 10+ Funcionalidades de Protocolo - DEX Nativa - NFTs Integrados - Sem Overhead em Tempo de Execução -
-
- - -
-

- Camada de Protocolo -

- - -
-
- Programabilidade -

- Hooks: Lógica de -
- Contrato Inteligente -
- no Nível da Conta -

-

- 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. -

-

- 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. -

-
-
- Hooks smart contract logic illustration -
-
- - -
-
- Exchange -

Offers: Exchange Descentralizado (DEX) Nativo

-

- 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. -

-

- 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. -

-
- -
- Economia -

Taxas Baixas com Queima de Taxas

-

- 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. -

-

- 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. -

-
-
- - -
- Infraestrutura -

Rápido, Verde e Escalável

-
-

- 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. -

-

- 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. -

-
-
-
- - -
-

- Primitivas Financeiras -

- - -
-
- Pagamentos -

- Pagamentos: -
- Transferências Multi-Ativo -
- & Canais -

-

- 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. -

-

- 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. -

-

- 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. -

-
-
- Global network infrastructure illustration -
-
- - -
-
- Controle de Ativos -

Controle de Tokens e Ativos por Design

-

- 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. -

-

- 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. -

-
- -
- Economia -

Recompensas de Saldo: Rendimento Passivo Sem Staking

-

- 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. -

-

- 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. -

-
-
- - -
-
- Primitivas -

Escrow: Transferências Condicionais para Qualquer Ativo

-

- 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. -

-

- 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. -

-
- -
- Pagamentos -

Remit: Transferências Nativas Entre Contas

-

- 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. -

-

- 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. -

-
- -
- Pagamentos -

Checks: Sistema de Pagamento Diferido

-

- 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. -

-

- 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. -

-
-
-
- - -
-

- Governança & Identidade -

- - -
-
- Governança -

- Jogo de Governança: -
- Coordenação Descentralizada -
- com Propósito -

-

- 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. -

-

- 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. -

-
-
- Consensus mechanism illustration -
-
- - -
-
- NFTs -

URITokens: NFTs Nativos no Xahau

-

- 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. -

-

- 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. -

-
-
-
-
- - diff --git a/src/i18n/aboutTranslations.ts b/src/i18n/aboutTranslations.ts index 42c5a63..1e6ecea 100644 --- a/src/i18n/aboutTranslations.ts +++ b/src/i18n/aboutTranslations.ts @@ -131,4 +131,48 @@ export const aboutTranslations = { act3_para3: 'XAHはBitrue、BitMart、CoinExなどの主要取引所で利用可能で、Ledgerハードウェアウォレットもサポートされており、世界中のユーザーにとってますますアクセスしやすくなっています。カスタムロジックのためにHooksに依存するプロジェクトは、継続的な手数料をカバーするための月次調整を生成するのに十分なXAH残高を維持することをお勧めします。', }, + 'pt-BR': { + page_title: 'Sobre Xahau', + page_subtitle: + 'Blockchain L1 empresarial com programabilidade baseada em contas', + chip1: 'Est. outubro 2023', + chip2: '200k+ contas', + chip3: '~4s de liquidação', + chip4: '10k tx / ledger', + + act1_label: 'A Rede', + act1_section_label: 'Visão geral', + act1_h3_line1: 'O que é Xahau?', + act1_h3_line2: 'A explicação breve', + act1_para1: + 'Xahau é uma blockchain L1 construída para programabilidade séria — combinando tecnologia de ledger comprovada com uma abordagem poderosa e distinta para contratos inteligentes, conhecidos como Hooks.', + act1_para2: + 'A tecnologia liquida transações em aproximadamente 4 segundos a custos de apenas frações de um centavo de USD. Com capacidade para processar até 10.000 transações por ledger, a rede é inerentemente verde e eficiente energeticamente por design.', + act1_para3: + 'Xahau oferece recursos nativos para emitir e negociar moedas na exchange descentralizada integrada, tokens não fungíveis nativos, transações atômicas multi-ativo por meio do transactor Remit, e oportunidades ilimitadas para DeFi através de Hooks — o sistema de contratos inteligentes baseado em contas do Xahau.', + act1_para4: + 'Os Hooks residem diretamente nas contas, respondendo a eventos de transação como pagamentos recebidos, enviados ou roteados. Desenvolvidos originalmente em C, os Hooks agora suportam qualquer linguagem compilável com WebAssembly. O suporte para Hooks em JavaScript (JSHooks) avança por meio de auditorias de segurança, aproximando as finanças programáveis de dezenas de milhões de desenvolvedores em todo o mundo.', + + act2_label: 'O Protocolo', + act2_section_label: 'Tecnologia', + act2_h3_line1: 'Qual é a tecnologia', + act2_h3_line2: 'por trás do Xahau?', + act2_para1: + 'Xahau é tecnologia comprovada e pronta para produção — uma iteração evoluída do código do XRP Ledger, aprimorada com programabilidade de contratos inteligentes baseada em contas (Hooks), suporte nativo igualitário para moedas emitidas em recursos como garantias e canais de pagamento, e uma camada de transações atômicas que permite executar operações complexas e de múltiplas etapas como uma unidade indivisível.', + act2_para2: + 'Xahau utiliza um mecanismo de Consenso Federado para validar transações. Servidores independentes chamados validadores alcançam um acordo sobre a ordem e resultado de cada transação. Todos os servidores processam cada transação de acordo com as mesmas regras, e qualquer transação válida é confirmada em segundos. Toda a atividade é pública e transparente, e qualquer pessoa pode operar um validador.', + act2_para3: + 'A governança da rede é guiada por um jogo de governança estruturado que garante uma tomada de decisão impulsionada pela comunidade. Os participantes em um sistema de mesas de dois níveis emitem votos sobre assentos de rede, emendas de Hooks e parâmetros de recompensas — dando ao ecossistema uma influência genuína e contínua sobre a direção da rede.', + + act3_label: 'A Moeda', + act3_section_label: 'Economia', + act3_h3_line1: 'XAH, a moeda nativa', + act3_h3_line2: 'do Xahau', + act3_para1: + 'A moeda nativa do Xahau é XAH — um ativo inflacionário projetado para recompensar a participação ativa. Cada conta pode reivindicar um ajuste mensal de saldo interagindo com um Hook na conta gênesis, acumulando 4% do saldo da conta a cada mês.', + act3_para2: + 'XAH atua como um mecanismo anti-spam da rede, adicionando um custo a cada transação. Transações padrão custam frações de um único XAH; operações impulsionadas por Hooks têm taxas proporcionalmente mais altas, refletindo sua carga computacional na cadeia. XAH também é necessário como reserva bloqueada para manter contas, possuir objetos e armazenar dados usados por contratos inteligentes.', + act3_para3: + 'XAH está disponível em exchanges principais como Bitrue, BitMart e CoinEx, e conta com suporte em carteiras hardware Ledger — tornando-o cada vez mais acessível para usuários em todo o mundo. Projetos que dependem de Hooks para lógica personalizada devem manter um saldo de XAH suficiente para gerar ajustes mensais que cubram as taxas contínuas.', + }, } diff --git a/src/i18n/featuresTranslations.ts b/src/i18n/featuresTranslations.ts index 1430534..a57cad3 100644 --- a/src/i18n/featuresTranslations.ts +++ b/src/i18n/featuresTranslations.ts @@ -364,4 +364,125 @@ export const featuresTranslations = { uri_para2: 'この組み込みNFT標準により、クリエイターはカスタムコードをデプロイすることなく、シンプルな取引（例：URITokenMint、URITokenBuy、URITokenBurn）でNFTをミント、取引、または燃焼させることができます。URITokenの発行者はフラグを設定することで破壊（燃焼）を許可することもでき、NFTの管理方法に柔軟性を与えます。プロトコルレベルでNFTを統合することで、Xahauはデジタルコレクティブルや資格情報の発行・管理をより効率的かつ安全にします。', }, + 'pt-BR': { + // Page header + page_title: 'Recursos', + page_subtitle: 'Tecnologia comprovada com uma abordagem inovadora', + chip1: '10+ Recursos de Protocolo', + chip2: 'DEX Nativo', + chip3: 'NFTs Integrados', + chip4: 'Sem Sobrecarga de Execução', + + // Act I — Protocol Layer + act1_label: 'Camada de Protocolo', + + // Hooks statement + proto_section_label: 'Programabilidade', + proto_h3_line1: 'Hooks: Lógica de Contrato Inteligente', + proto_h3_line2: 'a Nível de Conta', + proto_para1: + 'Xahau introduz os Hooks, uma forma única de lógica de contrato inteligente on-ledger que é executada diretamente a nível de 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 incorporados dentro das próprias contas de usuário. Esses Hooks podem inspecionar, modificar ou rejeitar automaticamente qualquer transação que envolva essa conta, sem a necessidade de chamadas de função explícitas.', + proto_para2: + 'Como os Hooks são executados inline e dentro do consenso, eles oferecem programabilidade em tempo real com sobrecarga mínima. Rejeite transferências de tokens não autorizadas, acione ações em depósitos, implemente lógica de conformidade — tudo sem desacelerar a rede. Os Hooks representam um novo paradigma de segurança e programabilidade.', + + // DEX detail + dex_label: 'Exchange', + dex_h4: 'Ofertas: Exchange Descentralizado (DEX) Integrado', + dex_para1: + 'Xahau inclui um sistema nativo de Ofertas, que alimenta um exchange descentralizado integrado no ledger. Os usuários podem criar entradas de Oferta para comprar ou vender ativos diretamente na rede; essas Ofertas são automaticamente combinadas pelo livro de ordens do protocolo. Troca peer-to-peer sem intermediários ou plataformas externas.', + dex_para2: + 'Ao contrário da maioria das blockchains que exigem contratos inteligentes para negociação, o DEX do Xahau é um recurso de primeira classe do ledger — liquidação rápida, baixas taxas, integração perfeita.', + + // Fees detail + fees_label: 'Economia', + fees_h4: 'Baixas Taxas com Queima de Fees', + fees_para1: + 'Taxas de transação consistentemente baixas, apoiadas por um modelo integrado de queima de taxas que reduz o spam e recompensa a saúde a longo prazo da rede. Cada transação paga uma taxa mínima em XAH; uma parte é destruída permanentemente — um efeito deflacionário silencioso.', + fees_para2: + 'Essa abordagem dissuade o abuso da rede enquanto mantém a acessibilidade. Diferente de modelos inflacionários ou taxas em formato de leilão, o Xahau fornece previsibilidade e alinhamento econômico para todos os usuários.', + + // Performance solo + perf_label: 'Infraestrutura', + perf_h4: 'Rápido, Verde e Escalável', + perf_para1: + 'Construído sobre uma versão refinada do protocolo de consenso do XRPL, o Xahau oferece finalização rápida, baixo consumo de energia e escalabilidade confiável. As transações são confirmadas em segundos — sem mineração, requisitos mínimos de hardware.', + perf_para2: + 'A arquitetura do Xahau é ideal para sistemas de pagamento globais, plataformas de ativos tokenizados ou aplicativos de alto volume onde desempenho e sustentabilidade são inegociáveis.', + + // Act II — Financial Primitives + act2_label: 'Primitivas Financeiras', + + // Payments statement + pay_section_label: 'Pagamentos', + pay_h3_line1: 'Transferências Multi-Ativo', + pay_h3_line2: 'e Canais de Pagamento', + pay_h3_line3: '', + pay_para1: + 'As funcionalidades de pagamento do Xahau são projetadas para facilitar transferências rápidas e flexíveis de valor em toda a rede. O Xahau suporta pagamentos multi-ativo por meio de um sistema de linhas de confiança e moedas emitidas, permitindo suporte integrado para múltiplas moedas e tokens sem a necessidade de contratos inteligentes.', + pay_para2: + 'Isso significa que as empresas podem emitir stablecoins ou tokens no Xahau, e os usuários podem enviá-los, recebê-los ou trocá-los nativamente. A suíte de Pagamentos também inclui recursos avançados como Preautorização de Depósito, que permite às contas colocar em uma lista branca quem pode enviar fundos para elas — adicionando segurança contra transações indesejadas.', + pay_para3: + '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 off-ledger, com liquidação on-chain do resultado líquido posteriormente. Com transações como PaymentChannelCreate, Fund e Claim, o Xahau possibilita micropagamentos e pagamentos em streaming que são protegidos pelo ledger sem congestioná-lo.', + + // Tokens detail + tokens_label: 'Controle de Ativos', + tokens_h4: 'Controle de Tokens e Ativos por Design', + tokens_para1: + 'O Xahau dá controle granular sobre tokens e linhas de confiança a emissores e usuários. Recursos como TrustSet, Clawback, Freeze e Deposit Authorization permitem personalização completa sobre como os tokens podem ser usados ou recebidos. Os ativos podem ser colocados em uma lista branca, bloqueados ou queimados — tudo aplicado a nível de protocolo.', + tokens_para2: + 'Isso torna o Xahau particularmente adequado para cenários onde conformidade, segurança e precisão são críticos, como instrumentos financeiros regulamentados, stablecoins, programas de fidelidade ou cadeias de suprimentos empresariais.', + + // Rewards detail + rewards_label: 'Economia', + rewards_h4: 'Recompensas de Saldo: Rendimento Passivo Sem Staking', + rewards_para1: + 'O Xahau oferece um sistema de recompensas de saldo onde as contas acumulam valor passivamente simplesmente mantendo ativos. Essas recompensas são calculadas com base no saldo da conta e distribuídas por meio de um mecanismo aplicado por consenso — sem necessidade de staking, delegação ou contratos de terceiros.', + rewards_para2: + 'Esse mecanismo é sustentado por lógica nativa do protocolo e Hooks on-chain para garantir que as recompensas sejam automáticas, justas e sustentáveis. Diferente dos sistemas de yield farming ou staking em outras blockchains, o modelo de recompensas do Xahau não requer que os usuários bloqueiem seus ativos ou persigam estratégias DeFi complexas.', + + // Escrow detail + escrow_label: 'Primitivas', + escrow_h4: 'Escrow', + escrow_para1: + 'O Xahau suporta escrow on-ledger para tokens nativos e emitidos, permitindo transferências condicionais seguras para uma ampla gama de casos de uso comerciais e financeiros. Os fundos ou tokens podem ser bloqueados com lógica de liberação baseada em tempo ou condições, aplicada pela própria rede — sem necessidade de contratos inteligentes externos.', + escrow_para2: + 'O suporte nativo para ambos os ativos fungíveis e não fungíveis em escrow torna esse recurso particularmente versátil para casos como pagamentos por marcos, liquidação de marketplace ou distribuição de confiança.', + + // Remit detail + remit_label: 'Pagamentos', + remit_h4: 'Remit: Transferência Nativa entre Contas', + remit_para1: + 'A funcionalidade Remit permite transações de múltiplas operações simplificadas entre contas, ideal para fluxos de pagamento complexos ou de alto volume. Em vez de enviar várias instruções separadas, uma única transação Remit pode distribuir valor para múltiplos destinatários ou acionar múltiplas mudanças de saldo de forma atômica — tudo sem a necessidade de uma pilha separada de instruções.', + remit_para2: + 'Isso melhora a eficiência e confiabilidade, especialmente para processadores de pagamento, marketplaces ou qualquer aplicativo que precise executar operações agrupadas. Integrado ao protocolo, o Remit garante desempenho previsível, baixa latência e forte auditabilidade.', + + // Checks detail + checks_label: 'Pagamentos', + checks_h4: 'Cheques: Sistema de Pagamento Diferido', + checks_para1: + 'O Xahau suporta um sistema de pagamento diferido — como escrever cheques digitais on-chain. Você pode emitir um Cheque, que é uma promessa de pagamento que o destinatário pode cobrar posteriormente ou cancelar se necessário. Isso adiciona uma camada extra de controle sobre os pagamentos, permitindo transações seguras e flexíveis.', + checks_para2: + 'O ledger tem transações dedicadas para criar, cobrar ou cancelar cheques. O sistema de cheques do Xahau fornece uma camada adicional de controle de pagamento aplicada pelas regras da rede, sem a necessidade de contratos inteligentes personalizados.', + + // Act III — Governance & Identity + act3_label: 'Governança e Identidade', + + // Governance statement + gov_section_label: 'Governança', + gov_h3_line1: 'O Jogo da Governança:', + gov_h3_line2: 'Coordenação Descentralizada', + gov_h3_line3: 'com Propósito', + gov_para1: + 'O Xahau apresenta um novo sistema de governança apoiado pelo Jogo da Governança — um mecanismo transparente e on-ledger para propor, revisar e votar emendas. Os operadores de validadores (Governadores) participam diretamente na formação do protocolo, competindo em um sistema de recompensas estruturado baseado em responsabilidade e engajamento.', + gov_para2: + 'Isso 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 — estabelecendo um novo padrão para coordenação on-chain.', + + // URITokens closing + uri_label: 'NFTs', + uri_h4: 'URITokens: NFTs Nativos no Xahau', + uri_para1: + 'Os URITokens representam a abordagem do Xahau para tokens não fungíveis — implementados como parte nativa do ledger, não por meio de contratos inteligentes separados. Um URIToken é um objeto on-ledger de primeira classe, identificado exclusivamente pela conta emissora e pelo Uniform Resource Identifier (URI) que normalmente aponta para os metadados ou conteúdo do token. Apenas um URIToken com um URI específico pode existir por conta, garantindo a verdadeira unicidade de cada ativo digital.', + uri_para2: + 'Esse padrão NFT incorporado permite que os criadores mintem, negociem ou queimem NFTs com transações simples — URITokenMint, URITokenBuy, URITokenBurn — sem a necessidade de implantar código personalizado. O emissor de um URIToken também pode permitir a queima definindo uma flag, oferecendo flexibilidade sobre como os NFTs podem ser gerenciados. Ao integrar NFTs a nível de protocolo, o Xahau torna a emissão e gestão de colecionáveis digitais ou credenciais mais eficiente e segura.', + }, } diff --git a/src/i18n/fraudReportTranslations.ts b/src/i18n/fraudReportTranslations.ts index cbebbba..9d8f4a4 100644 --- a/src/i18n/fraudReportTranslations.ts +++ b/src/i18n/fraudReportTranslations.ts @@ -371,4 +371,107 @@ export const fraudReportTranslations: Record = 'ネットワークエラー: サーバーに接続できませんでした。接続を確認して再度お試しください。', }, }, + 'pt-BR': { + frontmatter: { + title: 'Reportar Fraude', + description: + 'Você foi vítima de um golpe ou hack? Aqui está o que fazer!', + }, + intro: { + body: 'Xahau é uma blockchain pública, sem uma entidade governante que possa congelar ou recuperar fundos, fechar contas ou impedir de outra forma que as pessoas acessem seus ativos.', + warning: 'Não podemos reverter ou cancelar transações, ninguém pode.', + lead: 'Podemos marcar contas usadas para atividades ilícitas, o que irá:', + bullets: [ + 'Ser incluída em nossa API que exchanges e outras entidades estão usando para monitorar depósitos para conformidade AML e possivelmente reter fundos ilícitos.', + 'O movimento de fundos será rastreado automaticamente e receberemos notificações sempre que eles se moverem, não importa quão antigo seja o caso.', + 'Em caso de golpe, avisar outros usuários através do software de carteiras e exchanges usando nossa API, para não enviar fundos para uma conta marcada.', + ], + steps: [ + { + title: '1. Envie o endereço para o Xahau Forensics', + body: 'Mantemos o maior registro de endereços fraudulentos no Xahau e várias entidades o utilizam para combater atividades ilícitas.', + }, + { + title: '2. Reporte seu caso às autoridades', + body: 'Reporte à polícia local e, se seu país tiver um formulário de denúncia online para crimes cibernéticos ou financeiros, reporte lá também.', + }, + { + title: '3. Acompanhe seu boletim de ocorrência', + body: 'Trabalhamos com as autoridades. Deixe-os saber que temos as informações. As chances são de que também estamos em contato com outras vítimas e podemos ajudar as autoridades a combinar casos entre jurisdições e fornecer inteligência acionável.', + }, + ], + expectationTitle: 'O que você pode esperar?', + expectations: [ + 'Não podemos reverter ou cancelar transações, ninguém pode.', + 'Fazemos o nosso melhor para que os fundos sejam apreendidos quando saírem do Xahau, trabalhando com exchanges e outras rampas de saída através de nossa API de registro de endereços fraudulentos e por meio de contato manual.', + 'Quando você nos reporta uma conta, pode esperar que tratemos seu relatório com tanta atenção quanto qualquer outro relatório.', + 'Recebemos muitos relatórios todos os dias. Se uma conta for adicionada ao nosso registro de endereços fraudulentos, estamos cuidando dela da melhor forma possível junto com todos os outros casos.', + 'Se dinheiro for apreendido, entraremos em contato com você, se você nos deixou uma maneira de entrar em contato.', + 'Para recuperar fundos, você precisa trabalhar com as autoridades para a papelada.', + ], + expectationWarning: + 'Monitoramos centenas de casos ao mesmo tempo e não podemos dar suporte individualizado. Só entraremos em contato se tivermos boas notícias!', + }, + form: { + successTitle: 'Sucesso!', + successBody: 'Obrigado por seu relatório. Ele foi enviado com sucesso.', + reportIdLabel: 'ID do Relatório:', + reportIdFallback: 'desconecido', + errorTitle: 'Erro', + addressLabel: 'Endereço Xahau', + addressPlaceholder: 'rXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX', + addressHint: + 'Digite o endereço Xahau associado à atividade fraudulenta', + descriptionLabel: 'Descrição', + descriptionPlaceholder: 'Descreva a atividade fraudulenta', + descriptionHint: + 'Forneça o máximo de detalhes possível para nos ajudar a investigar', + urlLabel: 'URL', + urlPlaceholder: 'URL opcional relacionada à fraude', + urlHint: + 'Forneça uma URL se relevante, por exemplo, um site de golpe ou postagem em redes sociais', + categoryLabel: 'Categoria Sugerida', + categoryPlaceholder: 'Selecione uma categoria...', + categoryOptions: [ + { value: 'giveaway', label: 'Sorteio' }, + { value: 'theft', label: 'Roubo' }, + { value: 'other', label: 'Outro' }, + ], + categoryHint: 'Ajude-nos a categorizar o tipo de fraude', + contactLabel: 'Informações de Contato', + contactPlaceholder: + 'Informações de contato opcionais, por exemplo, e-mail, X handle ou nome de usuário do Telegram', + contactHint: + 'Forneça informações de contato se estiver disposto a ajudar com perguntas de acompanhamento', + requiredFields: 'Campos obrigatórios', + submitLabel: 'Enviar Relatório', + submitAnotherLabel: 'Enviar Outro Relatório', + optional: 'Opcional', + }, + privacy: { + title: 'Privacidade e Segurança', + bullets: [ + 'Este formulário usa ALTCHA, um CAPTCHA compatível com a privacidade que não rastreia você', + 'Seu relatório é enviado com segurança para a rede Xahau Forensics', + 'Os relatórios são revisados e usados para melhorar a segurança da rede', + 'Nenhuma informação pessoal é necessária para enviar um relatório', + ], + }, + attribution: { + prefix: 'Xahau Forensics é operado por ', + label: 'INFTF', + suffix: '.', + }, + messages: { + captchaIncomplete: + 'Por favor, complete a verificação CAPTCHA antes de enviar.', + captchaFailed: + 'Falha na verificação CAPTCHA. Por favor, complete o desafio e tente novamente.', + submitting: 'Enviando...', + submitFailed: + 'Falha ao enviar o relatório. Por favor, tente novamente.', + networkError: + 'Erro de rede: Não foi possível conectar ao servidor. Verifique sua conexão e tente novamente.', + }, + }, } diff --git a/src/pages/pt-br/about.astro b/src/pages/pt-br/about.astro index e5421d3..a0d261d 100644 --- a/src/pages/pt-br/about.astro +++ b/src/pages/pt-br/about.astro @@ -1,6 +1,6 @@ --- import '../../styles/main.css' -import XahauAbout from '../../components/XahauAboutPtBR.astro' +import XahauAbout from '../../components/XahauAbout.astro' import BaseLayout from '../../layouts/BaseLayout.astro' const _frontmatter = { diff --git a/src/pages/pt-br/features.astro b/src/pages/pt-br/features.astro index eccdd59..8dcca9f 100644 --- a/src/pages/pt-br/features.astro +++ b/src/pages/pt-br/features.astro @@ -1,6 +1,6 @@ --- import '../../styles/main.css' -import XahauFeatures from '../../components/XahauFeaturesPtBR.astro' +import XahauFeatures from '../../components/XahauFeatures.astro' import BaseLayout from '../../layouts/BaseLayout.astro' const _frontmatter = { diff --git a/src/pages/pt-br/fraud-report.astro b/src/pages/pt-br/fraud-report.astro index fb6822d..1be1bf2 100644 --- a/src/pages/pt-br/fraud-report.astro +++ b/src/pages/pt-br/fraud-report.astro @@ -3,4 +3,4 @@ import FraudReportPage from '../../components/FraudReportPage.astro' import { fraudReportTranslations } from '../../i18n/fraudReportTranslations' --- - + From a4886837879cef64ec3f51568c5aeb31adb86109 Mon Sep 17 00:00:00 2001 From: Andrei Rosseti Date: Wed, 22 Apr 2026 17:32:20 -0300 Subject: [PATCH 11/20] feat: translate pt-br hooks concepts --- .../docs/hooks/concepts/collect-call.mdx | 26 +- .../docs/hooks/concepts/compiling-hooks.mdx | 58 ++--- .../docs/hooks/concepts/debugging-hooks.mdx | 56 ++--- .../hooks/concepts/emitted-transactions.mdx | 74 +++--- .../hooks/concepts/execution-metadata.mdx | 26 +- .../concepts/floating-point-numbers-xfl.mdx | 98 ++++---- .../docs/pt-br/docs/hooks/concepts/grants.mdx | 62 ++--- .../pt-br/docs/hooks/concepts/hook-fees.mdx | 46 ++-- .../docs/hooks/concepts/hookon-field.mdx | 30 +-- .../hooks/concepts/loops-and-guarding.mdx | 50 ++-- .../pt-br/docs/hooks/concepts/namespaces.mdx | 32 +-- .../pt-br/docs/hooks/concepts/parameters.mdx | 36 +-- .../reference-counted-hook-definitions.mdx | 18 +- .../hooks/concepts/serialized-objects.mdx | 44 ++-- .../hooks/concepts/sethook-transaction.mdx | 214 ++++++++-------- .../docs/hooks/concepts/slots-and-keylets.mdx | 62 ++--- .../docs/hooks/concepts/state-management.mdx | 34 +-- .../pt-br/docs/hooks/concepts/terminology.mdx | 57 +++-- .../docs/hooks/concepts/weak-and-strong.mdx | 238 +++++++++--------- 19 files changed, 630 insertions(+), 631 deletions(-) diff --git a/src/content/docs/pt-br/docs/hooks/concepts/collect-call.mdx b/src/content/docs/pt-br/docs/hooks/concepts/collect-call.mdx index 2ecb07d..8ec8eaa 100644 --- a/src/content/docs/pt-br/docs/hooks/concepts/collect-call.mdx +++ b/src/content/docs/pt-br/docs/hooks/concepts/collect-call.mdx @@ -1,27 +1,27 @@ --- -title: Collect Call +title: Chamada Coletiva --- import { Card, Aside } from '@astrojs/starlight/components'; - -_Every party affected by a transaction should have the opportunity to have their hooks executed._ + +_Toda parte afetada por uma transação deve ter a oportunidade de ter seus hooks executados._ -When hooks are not Strongly Executed it is unfair to bill the originating transaction for their execution. For example an _OfferCreate_ which crosses 20 offers on the DEX should not be forced to pay for the execution of each of those account's Hooks. +Quando os hooks não são Fortemente Executados, não é justo cobrar da transação de origem o custo de sua execução. Por exemplo, um _OfferCreate_ que cruza 20 ofertas na DEX não deve ser obrigado a pagar pela execução dos Hooks de cada uma dessas contas. -Therefore during typical Weak execution the fee for the execution is collected from the owner of the Hook. To enable this: +Portanto, durante uma execução Fraca típica, a taxa de execução é cobrada do proprietário do Hook. Para habilitar isso: -* The Hook owner must have set `asfTshCollect` on their Xahau account using the AccountSet transaction. -* The Hook owner must have set `hsfCollect` on the specific Hook they wish to be called as a Weak TSH. +* O proprietário do Hook deve ter definido `asfTshCollect` em sua conta Xahau usando a transação AccountSet. +* O proprietário do Hook deve ter definido `hsfCollect` no Hook específico que deseja que seja chamado como um TSH Fraco. -### Fee Responsibility Table +### Tabela de Responsabilidade de Taxa -| Type of Weak Execution | Fee | +| Tipo de Execução Fraca | Taxa | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -|

Again As Weak
- Happens when a Strongly Executed Hook calls hook_again

| Free (already paid by the Strong Execution). | -|

Callback
- Happens when an emitted transaction either makes it into a ledger or is flagged as being impossible to ever make it into a ledger.

| Free (already paid during Emission). | -|

Weak Transactional Stakeholder
- Happens if a transaction in some way mildly affects your account.

| Paid for by your account (not by the originating transaction) if and only if both your account is marked with `asfTshCollect` flag and your Hook is marked with the `hsfCollect` flag. | +|

Again As Weak
- Ocorre quando um Hook Fortemente Executado chama hook_again

| Gratuita (já paga pela Execução Forte). | +|

Callback
- Ocorre quando uma transação emitida entra em um ledger ou é sinalizada como impossível de entrar em qualquer ledger.

| Gratuita (já paga durante a Emissão). | +|

Parte Interessada Transacional Fraca
- Ocorre quando uma transação afeta levemente sua conta de alguma forma.

| Paga pela sua conta (não pela transação de origem) se e somente se sua conta estiver marcada com o flag `asfTshCollect` e seu Hook estiver marcado com o flag `hsfCollect`. | diff --git a/src/content/docs/pt-br/docs/hooks/concepts/compiling-hooks.mdx b/src/content/docs/pt-br/docs/hooks/concepts/compiling-hooks.mdx index 293bf53..34ebd16 100644 --- a/src/content/docs/pt-br/docs/hooks/concepts/compiling-hooks.mdx +++ b/src/content/docs/pt-br/docs/hooks/concepts/compiling-hooks.mdx @@ -1,31 +1,31 @@ --- -title: Compiling Hooks +title: Compilando Hooks --- import { Aside } from '@astrojs/starlight/components'; -### Constraints +### Restrições -All Hooks are compiled to a single [webassembly module](https://webassembly.github.io/spec/core/syntax/modules.html) before they can be set onto an Xahau account. +Todos os Hooks são compilados em um único [módulo webassembly](https://webassembly.github.io/spec/core/syntax/modules.html) antes de poderem ser instalados em uma conta Xahau. -A Hook always implements and exports exactly one or both of the following functions: +Um Hook sempre implementa e exporta exatamente uma ou ambas das seguintes funções: -`int64_t hook(uint32_t ctx) { ... }` _required_ +`int64_t hook(uint32_t ctx) { ... }` _obrigatória_ -* Executed whenever a transaction comes into or leaves from the account the Hook is set on (`ctx = 0`) or -* Executed when executed as a [Weak Transactional Stakeholder](/pt-br/docs/hooks/concepts/weak-and-strong) (`ctx > 0`). +* Executada sempre que uma transação chega ou sai da conta onde o Hook está instalado (`ctx = 0`) ou +* Executada quando executada como uma [Parte Interessada Transacional Fraca](/pt-br/docs/hooks/concepts/weak-and-strong) (`ctx > 0`). -`int64_t cbak(uint32_t ctx) { ... }` _optional_ +`int64_t cbak(uint32_t ctx) { ... }` _opcional_ -* Executed when an emitted transaction is successfully accepted into a ledger (`ctx = 0`) or -* Executed when an emitted transaction cannot be accepted into any ledger (`ctx = 1`). +* Executada quando uma transação emitida é aceita com sucesso em um ledger (`ctx = 0`) ou +* Executada quando uma transação emitida não pode ser aceita em nenhum ledger (`ctx = 1`). -Hooks are not allowed to specify other functions. Instead they must make clever use of macros to do all their computation within these two functions. This is part of a computational restriction on hooks to keep their runtime predictable. +Os Hooks não podem especificar outras funções. Em vez disso, devem usar macros de forma inteligente para realizar todos os cálculos dentro dessas duas funções. Essa é parte de uma restrição computacional dos hooks para manter seus tempos de execução previsíveis. -Additionally Hooks are afforded no _heap_ memory. All required memory must be reserved and used on the stack. +Adicionalmente, os Hooks não têm acesso a memória _heap_. Toda a memória necessária deve ser reservada e utilizada na pilha. -### Example +### Exemplo -Here is an example Hook written in C. The Hook prints 0...3 to the trace log before accepting the originating transaction. +Aqui está um exemplo de Hook escrito em C. O Hook imprime 0...3 no log de rastreamento antes de aceitar a transação de origem. ```c #include @@ -46,12 +46,12 @@ int64_t hook(uint32_t ctx) ``` -### Compilation +### Compilação -A [variety of compilers](https://www.google.com/search?q=webassembly+compiler+C) will generate valid webassembly from a C source file. Once compiled, a Hook exists as a binary `.wasm` file. This contains a webassembly module. Using `wasmcc` to compile and the `wasm2wat` tool to convert to human readable webassembly this binary form can be rendered to the human readable form. Below appears the compilation result of the above example. +Uma [variedade de compiladores](https://www.google.com/search?q=webassembly+compiler+C) irá gerar webassembly válido a partir de um arquivo fonte C. Uma vez compilado, um Hook existe como um arquivo binário `.wasm`. Este contém um módulo webassembly. Usando `wasmcc` para compilar e a ferramenta `wasm2wat` para converter para webassembly legível, essa forma binária pode ser renderizada para a forma legível. Abaixo aparece o resultado da compilação do exemplo acima. ``` (module @@ -201,28 +201,28 @@ A [variety of compilers](https://www.google.com/search?q=webassembly+compiler+C) (data (;0;) (i32.const 1024) "test\00")) ``` -The average Hook developer will never need to examine webassembly directly. However it is a useful conceptual exercise to review the contents of the sample Hook. +O desenvolvedor médio de Hooks nunca precisará examinar o webassembly diretamente. No entanto, é um exercício conceitual útil revisar o conteúdo do Hook de exemplo. -Above we can see: +Acima podemos ver: -* Three functions are imported from the Hooks API (`_g`, `accept`, `trace_num`) -* Two functions are defined by the hook (`cbak`, `hook`) -* Two functions are exported by the hook (again: `cbak`, `hook`) -* Some static (constant) data is recorded in the hook (see `data` at the bottom). +* Três funções são importadas da API de Hooks (`_g`, `accept`, `trace_num`) +* Duas funções são definidas pelo hook (`cbak`, `hook`) +* Duas funções são exportadas pelo hook (novamente: `cbak`, `hook`) +* Alguns dados estáticos (constantes) são registrados no hook (veja `data` no final). -It is very important to note that a Hook _must only_ import functions available to it from the Hooks API and _must_ only export the `cbak` and `hook` functions. In additional all hooks must import `_g` from the Hooks API, which is the `guard` function. +É muito importante notar que um Hook _deve apenas_ importar funções disponíveis para ele da API de Hooks e _deve_ apenas exportar as funções `cbak` e `hook`. Adicionalmente, todos os hooks devem importar `_g` da API de Hooks, que é a função `guard`. -### Unwanted Exports +### Exportações Indesejadas -Most webassembly compilers (including the one above) produce additional exports for their own linking purposes. In many cases the generation of these is difficult or impossible to disable. +A maioria dos compiladores webassembly (incluindo o acima) produz exportações adicionais para seus próprios propósitos de vinculação. Em muitos casos, a geração dessas é difícil ou impossível de desativar. -Unwanted exports will lead to an otherwise valid Hook being rejected. Therefore after compilation developers should use the [Hook Cleaner Utility](https://github.com/XRPLF/hook-cleaner-c) to strip out these out. Failure to do so will lead to your Hook being rejected. +Exportações indesejadas levarão a um Hook de outra forma válido ser rejeitado. Portanto, após a compilação, os desenvolvedores devem usar o [Hook Cleaner Utility](https://github.com/XRPLF/hook-cleaner-c) para removê-las. Deixar de fazer isso resultará na rejeição do seu Hook. diff --git a/src/content/docs/pt-br/docs/hooks/concepts/debugging-hooks.mdx b/src/content/docs/pt-br/docs/hooks/concepts/debugging-hooks.mdx index a79b74e..f3da1aa 100644 --- a/src/content/docs/pt-br/docs/hooks/concepts/debugging-hooks.mdx +++ b/src/content/docs/pt-br/docs/hooks/concepts/debugging-hooks.mdx @@ -1,30 +1,30 @@ --- -title: Debugging Hooks -description: How to print "hello world" from your Hook! +title: Depurando Hooks +description: Como imprimir "hello world" a partir do seu Hook! --- import { Aside } from '@astrojs/starlight/components'; -### How can I debug a Hook? +### Como posso depurar um Hook? -The Hook API provides a set of functions in the namespace `trace` which write output to the `xrpld` log file when xrpld is configured with the _trace_ log-level. These functions, generally speaking, allow you to see the value of variables, buffers and otherwise trace the execution and state of a Hook at runtime. +A API de Hooks fornece um conjunto de funções no namespace `trace` que gravam saída no arquivo de log do `xrpld` quando o xrpld está configurado com o nível de log _trace_. Essas funções, em geral, permitem que você veja o valor de variáveis, buffers e rastreie a execução e o estado de um Hook em tempo de execução. -### Trace APIs +### APIs de Rastreamento -The following `trace` functions are available in the Hooks API +As seguintes funções `trace` estão disponíveis na API de Hooks -| Hook API | What it does | +| API de Hook | O que faz | | ----------------------------------------------------------------------- | ----------------------------------------------------------------------------------------- | -| [trace](/pt-br/docs/hooks/functions/trace-debug/trace) | Print a utf-8 message, followed by a user-specified buffer (this last optionally as hex.) | -| [trace_num](/pt-br/docs/hooks/functions/trace-debug/trace_num) | Print a utf-8 message, followed by an integer. | -| [trace_float](/pt-br/docs/hooks/functions/trace-debug/trace_float) | Print a utf-8 message, followed by an XFL Floating point number. | +| [trace](/pt-br/docs/hooks/functions/trace-debug/trace) | Imprime uma mensagem utf-8, seguida por um buffer especificado pelo usuário (opcionalmente como hex.) | +| [trace_num](/pt-br/docs/hooks/functions/trace-debug/trace_num) | Imprime uma mensagem utf-8, seguida por um inteiro. | +| [trace_float](/pt-br/docs/hooks/functions/trace-debug/trace_float) | Imprime uma mensagem utf-8, seguida por um número de ponto flutuante XFL. | -### Example +### Exemplo -The following code will print a single trace line then accept the Originating Transaction. +O código a seguir imprimirá uma única linha de rastreamento e então aceitará a Transação de Origem. ```c #include "../hookapi.h" @@ -36,7 +36,7 @@ int64_t hook(int64_t reserved) } ``` -An example of the log-line produced by `xahaud` when a payment is sent out of or into the Hook Account: +Um exemplo da linha de log produzida pelo `xahaud` quando um pagamento é enviado para fora ou para dentro da Conta Hook: ``` 2021-Apr-13 13:59:11.083700726 UTC View:TRC @@ -44,27 +44,27 @@ An example of the log-line produced by `xahaud` when a payment is sent out of or A number 10 ``` -The above appears in the log as all-one-line, but split here for visibility. +O acima aparece no log como uma única linha, mas foi dividido aqui para melhor visibilidade. -