From 90cd0be8b3fd9b87430814656e249efd73eec8a6 Mon Sep 17 00:00:00 2001 From: Crowdin Bot Date: Thu, 1 Aug 2024 13:24:59 +0000 Subject: [PATCH] New Crowdin translations by GitHub Action --- i18n/es/code.json | 420 ++++ .../2024-01-18.mdx | 33 + .../2024-01-26.mdx | 34 + .../2024-02-01.mdx | 28 + .../2024-02-09.mdx | 21 + .../2024-02-15.mdx | 44 + .../2024-02-22.mdx | 20 + .../2024-02-29.mdx | 21 + .../2024-03-07.mdx | 21 + .../2024-03-14.mdx | 25 + .../2024-03-21.mdx | 22 + .../2024-03-28.mdx | 21 + .../2024-04-04.mdx | 34 + .../2024-04-11.mdx | 22 + .../2024-04-18.mdx | 20 + .../2024-04-25.mdx | 25 + .../2024-05-02.mdx | 23 + .../2024-05-09.mdx | 19 + .../2024-06-13.mdx | 25 + .../2024-06-20.mdx | 20 + .../2024-06-27.mdx | 22 + .../2024-07-11.mdx | 18 + .../2024-07-18.mdx | 26 + .../authors.yml | 10 + .../options.json | 14 + .../current.json | 154 ++ .../current/README.mdx | 22 + .../current/anchor-platform/README.mdx | 12 + .../anchor-platform/admin-guide/README.mdx | 10 + .../admin-guide/architecture.mdx | 69 + .../component/observer/observer.mdx | 36 + .../admin-guide/component/rpc/error.mdx | 16 + .../admin-guide/component/rpc/request.mdx | 29 + .../admin-guide/component/rpc/response.mdx | 33 + .../admin-guide/component/rpc/rpc.mdx | 17 + .../component/security/api_key.mdx | 14 + .../admin-guide/component/security/jwt.mdx | 14 + .../component/security/security.mdx | 11 + .../admin-guide/custody-services/README.mdx | 11 + .../custody-services/configuration.mdx | 130 ++ .../custody-services/fireblocks/README.mdx | 11 + .../fireblocks/configuration.mdx | 68 + .../custody-services/fireblocks/example.mdx | 50 + .../admin-guide/events/README.mdx | 10 + .../admin-guide/events/delivery.mdx | 30 + .../admin-guide/events/getting-started.mdx | 8 + .../admin-guide/events/integration.mdx | 174 ++ .../admin-guide/getting-started.mdx | 382 ++++ .../anchor-platform/admin-guide/overview.mdx | 36 + .../admin-guide/sep1/README.mdx | 66 + .../admin-guide/sep10/README.mdx | 143 ++ .../admin-guide/sep24/README.mdx | 11 + .../admin-guide/sep24/configuration.mdx | 190 ++ .../admin-guide/sep24/example.mdx | 438 +++++ .../anchor-platform/admin-guide/sep24/faq.mdx | 39 + .../admin-guide/sep24/getting-started.mdx | 33 + .../admin-guide/sep24/integration.mdx | 1010 ++++++++++ .../sep24/setting-up-production-server.mdx | 112 ++ .../admin-guide/sep31/README.mdx | 11 + .../admin-guide/sep31/configuration.mdx | 382 ++++ .../admin-guide/sep31/getting-started.mdx | 21 + .../admin-guide/sep31/integration.mdx | 694 +++++++ .../admin-guide/sep6/README.mdx | 12 + .../admin-guide/sep6/configuration.mdx | 237 +++ .../admin-guide/sep6/getting-started.mdx | 33 + .../admin-guide/sep6/integration.mdx | 971 +++++++++ .../anchor-platform/api-reference/README.mdx | 10 + .../api-reference/callbacks/README.mdx | 19 + .../callbacks/customer/README.mdx | 22 + .../api-reference/callbacks/event/README.mdx | 20 + .../api-reference/callbacks/fee/README.mdx | 18 + .../api-reference/callbacks/rate/README.mdx | 16 + .../api-reference/callbacks/sidebar.ts | 163 ++ .../callbacks/unique-address/README.mdx | 22 + .../api-reference/custody-server/README.mdx | 19 + .../custody-transactions/README.mdx | 16 + .../custody-server/payments/README.mdx | 16 + .../custody-server/refunds/README.mdx | 16 + .../api-reference/custody-server/sidebar.ts | 116 ++ .../custody-server/unique-address/README.mdx | 16 + .../api-reference/resources/README.mdx | 16 + .../api-reference/resources/sidebar.ts | 64 + .../resources/transactions/README.mdx | 18 + .../api-reference/rpc/README.mdx | 11 + .../api-reference/rpc/methods/README.mdx | 42 + .../rpc/methods/do_stellar_payment/README.mdx | 30 + .../rpc/methods/do_stellar_refund/README.mdx | 30 + .../methods/notify_amounts_updated/README.mdx | 30 + .../notify_customer_info_updated/README.mdx | 30 + .../README.mdx | 30 + .../README.mdx | 30 + .../notify_offchain_funds_pending/README.mdx | 30 + .../notify_offchain_funds_received/README.mdx | 30 + .../notify_offchain_funds_sent/README.mdx | 30 + .../notify_onchain_funds_received/README.mdx | 30 + .../notify_onchain_funds_sent/README.mdx | 30 + .../methods/notify_refund_pending/README.mdx | 30 + .../rpc/methods/notify_refund_sent/README.mdx | 30 + .../notify_transaction_error/README.mdx | 30 + .../notify_transaction_expired/README.mdx | 30 + .../notify_transaction_on_hold/README.mdx | 30 + .../notify_transaction_recovery/README.mdx | 30 + .../rpc/methods/notify_trust_set/README.mdx | 30 + .../request_customer_info_update/README.mdx | 30 + .../methods/request_offchain_funds/README.mdx | 30 + .../methods/request_onchain_funds/README.mdx | 30 + .../rpc/methods/request_trust/README.mdx | 30 + .../api-reference/rpc/overview.mdx | 18 + .../api-reference/rpc/sidebar.js | 57 + .../stellar-disbursement-platform/README.mdx | 11 + .../admin-guide/README.mdx | 11 + .../anchor-platform-integration-points.mdx | 44 + .../admin-guide/configuring-sdp.mdx | 211 ++ .../admin-guide/deploy-the-sdp.mdx | 57 + .../admin-guide/design-and-architecture.mdx | 65 + .../admin-guide/getting-started.mdx | 414 ++++ .../making-your-wallet-sdp-ready.mdx | 176 ++ .../migrating-to-sdp-multi-tenant.mdx | 478 +++++ .../admin-guide/overview.mdx | 19 + .../admin-guide/secure-operation-manual.mdx | 44 + .../admin-guide/user-interface/README.mdx | 10 + .../admin-guide/user-interface/analytics.mdx | 20 + .../user-interface/dashboard-home.mdx | 44 + .../user-interface/disbursements.mdx | 26 + .../admin-guide/user-interface/payments.mdx | 22 + .../admin-guide/user-interface/receivers.mdx | 24 + .../admin-guide/user-interface/wallets.mdx | 19 + .../api-reference/README.mdx | 10 + .../api-reference/resources/README.mdx | 25 + .../api-reference/resources/admin/README.mdx | 20 + .../api-reference/resources/auth/README.mdx | 20 + .../resources/disbursements/README.mdx | 22 + .../resources/organization/README.mdx | 23 + .../resources/payments/README.mdx | 17 + .../resources/profile/README.mdx | 17 + .../resources/receivers/README.mdx | 20 + .../resources/registration/README.mdx | 33 + .../api-reference/resources/sidebar.ts | 283 +++ .../resources/statistics/README.mdx | 15 + .../api-reference/resources/users/README.mdx | 18 + .../current.json | 358 ++++ .../current/README.mdx | 35 + .../current/build/README.mdx | 35 + .../current/build/apps/README.mdx | 10 + .../application-design-considerations.mdx | 110 ++ .../current/build/apps/dapp-frontend.mdx | 444 +++++ .../account-creation.mdx | 195 ++ .../anchor-integration/sep1.mdx | 26 + .../anchor-integration/sep10.mdx | 321 +++ .../anchor-integration/sep24.mdx | 279 +++ .../anchor-integration/sep6.mdx | 320 +++ .../anchor-integration/setup.mdx | 46 + .../confirmation-modal.mdx | 250 +++ .../contacts-list.mdx | 150 ++ .../manage-trust.mdx | 201 ++ .../example-application-tutorial/overview.mdx | 270 +++ .../path-payment.mdx | 287 +++ .../example-application-tutorial/payment.mdx | 290 +++ .../querying-data.mdx | 345 ++++ .../ingest-sdk/ingestion-pipeline-code.mdx | 290 +++ .../build/apps/ingest-sdk/overview.mdx | 62 + .../moneygram-access-integration-guide.mdx | 789 ++++++++ .../current/build/apps/overview.mdx | 26 + .../current/build/apps/smart-wallets.mdx | 123 ++ .../current/build/apps/wallet/README.md | 96 + .../wallet/component/dart/configClient.mdx | 27 + .../apps/wallet/component/dart/install.mdx | 13 + .../build/apps/wallet/component/header.mdx | 12 + .../apps/wallet/component/kt/configClient.mdx | 56 + .../apps/wallet/component/kt/globalSigner.mdx | 13 + .../apps/wallet/component/kt/httpConfig.mdx | 14 + .../apps/wallet/component/kt/install.mdx | 12 + .../apps/wallet/component/kt/watcher.mdx | 31 + .../wallet/component/ts/allowHttpInfo.mdx | 17 + .../apps/wallet/component/ts/configClient.mdx | 24 + .../wallet/component/ts/createKeypairInfo.mdx | 17 + .../apps/wallet/component/ts/globalSigner.mdx | 17 + .../apps/wallet/component/ts/install.mdx | 9 + .../current/build/apps/wallet/intro.mdx | 160 ++ .../current/build/apps/wallet/overview.mdx | 17 + .../current/build/apps/wallet/sep10.mdx | 230 +++ .../current/build/apps/wallet/sep24.mdx | 622 ++++++ .../current/build/apps/wallet/sep30.mdx | 427 ++++ .../current/build/apps/wallet/sep38.mdx | 242 +++ .../current/build/apps/wallet/sep6.mdx | 445 +++++ .../current/build/apps/wallet/stellar.mdx | 929 +++++++++ .../current/build/guides/README.mdx | 8 + .../current/build/guides/archival/README.mdx | 8 + .../create-restoration-footprint-js.mdx | 7 + .../guides/archival/restore-contract-js.mdx | 74 + .../build/guides/archival/restore-data-js.mdx | 96 + .../guides/archival/test-ttl-extension.mdx | 172 ++ .../current/build/guides/basics/README.mdx | 8 + .../build/guides/basics/create-account.mdx | 293 +++ .../basics/follow-received-payments.mdx | 266 +++ .../basics/send-and-receive-payments.mdx | 801 ++++++++ .../current/build/guides/cli/README.mdx | 10 + .../build/guides/cli/deploy-contract.mdx | 14 + .../cli/deploy-stellar-asset-contract.mdx | 55 + .../guides/cli/extend-contract-instance.mdx | 24 + .../guides/cli/extend-contract-storage.mdx | 37 + .../build/guides/cli/extend-contract-wasm.mdx | 35 + .../build/guides/cli/install-deploy.mdx | 14 + .../current/build/guides/cli/install-wasm.mdx | 20 + .../guides/cli/restore-contract-instance.mdx | 15 + .../guides/cli/restore-contract-storage.mdx | 33 + .../build/guides/conventions/README.mdx | 8 + .../analyzing-smart-contract-cost.mdx | 595 ++++++ .../conventions/check-auth-tutorials.mdx | 1482 ++++++++++++++ .../guides/conventions/deploy-contract.mdx | 240 +++ .../build/guides/conventions/error-enum.mdx | 41 + .../install-deploy-contract-with-code.mdx | 247 +++ .../conventions/stellar-asset-contract.mdx | 104 + .../conventions/upgrading-contracts.mdx | 331 ++++ .../guides/conventions/wasm-metadata.mdx | 32 + .../conventions/work-contractspec-js.mdx | 7 + .../build/guides/conversions/README.mdx | 9 + .../guides/conversions/address-to-bytesn.mdx | 11 + .../guides/conversions/address-to-id.mdx | 7 + .../guides/conversions/id-to-address.mdx | 7 + .../current/build/guides/dapps/README.mdx | 8 + .../current/build/guides/dapps/docker.mdx | 137 ++ .../build/guides/dapps/initialization.mdx | 215 ++ .../current/build/guides/dapps/react.mdx | 141 ++ .../current/build/guides/events/README.mdx | 8 + .../current/build/guides/events/consume.mdx | 210 ++ .../current/build/guides/events/ingest.mdx | 320 +++ .../current/build/guides/events/publish.mdx | 51 + .../current/build/guides/fees/README.mdx | 9 + .../build/guides/fees/cost-analysis.mdx | 7 + .../current/build/guides/freighter/README.mdx | 8 + .../guides/freighter/connect-testnet.mdx | 13 + .../freighter/enable-soroban-tokens.mdx | 15 + .../freighter/integrate-freighter-react.mdx | 42 + .../guides/freighter/prompt-to-sign-tx.mdx | 13 + .../guides/freighter/send-token-payments.mdx | 17 + .../guides/freighter/sign-auth-entries.mdx | 11 + .../guides/freighter/sign-soroban-xdrs.mdx | 15 + .../current/build/guides/rpc/README.mdx | 8 + .../rpc/generate-ledger-keys-python.mdx | 31 + .../guides/rpc/retrieve-contract-code-js.mdx | 126 ++ .../rpc/retrieve-contract-code-python.mdx | 124 ++ .../build/guides/rpc/self-deploy-rpc.mdx | 7 + .../build/guides/rpc/use-public-rpc.mdx | 7 + .../current/build/guides/storage/README.mdx | 8 + .../build/guides/storage/choose-type.mdx | 7 + .../build/guides/storage/use-instance.mdx | 32 + .../build/guides/storage/use-persistent.mdx | 38 + .../build/guides/storage/use-temporary.mdx | 24 + .../current/build/guides/testing/README.mdx | 8 + .../guides/testing/basic-contract-tests.mdx | 27 + .../detecting-changes-with-test-snapshots.mdx | 53 + ...integration-testing-multiple-contracts.mdx | 7 + .../guides/testing/test-contract-auth.mdx | 43 + .../build/guides/testing/testnet-reset.mdx | 7 + .../build/guides/transactions/README.mdx | 10 + .../transactions/invoke-contract-tx-sdk.mdx | 355 ++++ .../simulateTransaction-Deep-Dive.mdx | 419 ++++ .../submit-transaction-wait-js.mdx | 61 + .../current/build/smart-contracts/README.mdx | 10 + .../example-contracts/README.mdx | 16 + .../example-contracts/TEMPLATE.mdx | 184 ++ .../example-contracts/alloc.mdx | 129 ++ .../example-contracts/atomic-multi-swap.mdx | 30 + .../example-contracts/atomic-swap.mdx | 262 +++ .../example-contracts/auth.mdx | 487 +++++ .../example-contracts/cross-contract-call.mdx | 326 ++++ .../example-contracts/custom-account.mdx | 359 ++++ .../example-contracts/custom-types.mdx | 301 +++ .../example-contracts/deployer.mdx | 539 +++++ .../example-contracts/errors.mdx | 415 ++++ .../example-contracts/events.mdx | 277 +++ .../example-contracts/fuzzing.mdx | 798 ++++++++ .../example-contracts/liquidity-pool.mdx | 925 +++++++++ .../example-contracts/logging.mdx | 282 +++ .../example-contracts/single-offer-sale.mdx | 28 + .../example-contracts/timelock.mdx | 30 + .../example-contracts/tokens.mdx | 1024 ++++++++++ .../getting-started/README.mdx | 10 + .../deploy-increment-contract.mdx | 139 ++ .../getting-started/deploy-to-testnet.mdx | 137 ++ .../getting-started/hello-world.mdx | 347 ++++ .../smart-contracts/getting-started/setup.mdx | 192 ++ .../getting-started/storing-data.mdx | 209 ++ .../build/smart-contracts/overview.mdx | 70 + .../current/data/README.mdx | 45 + .../current/data/READ_FIRST.md | 12 + .../current/data/horizon/README.mdx | 38 + .../data/horizon/admin-guide/README.mdx | 10 + .../data/horizon/admin-guide/configuring.mdx | 170 ++ .../admin-guide/ingestion-filtering.mdx | 97 + .../data/horizon/admin-guide/ingestion.mdx | 97 + .../data/horizon/admin-guide/installing.mdx | 78 + .../data/horizon/admin-guide/monitoring.mdx | 118 ++ .../data/horizon/admin-guide/overview.mdx | 17 + .../horizon/admin-guide/prerequisites.mdx | 60 + .../data/horizon/admin-guide/running.mdx | 123 ++ .../data/horizon/admin-guide/scaling.mdx | 57 + .../data/horizon/admin-guide/upgrading.mdx | 143 ++ .../data/horizon/api-reference/README.mdx | 10 + .../api-reference/aggregations/README.mdx | 19 + .../aggregations/fee-stats/README.mdx | 16 + .../aggregations/fee-stats/object.mdx | 169 ++ .../aggregations/order-books/README.mdx | 18 + .../aggregations/order-books/object.mdx | 130 ++ .../aggregations/paths/README.mdx | 19 + .../aggregations/paths/object.mdx | 136 ++ .../trade-aggregations/README.mdx | 16 + .../trade-aggregations/object.mdx | 239 +++ .../horizon/api-reference/errors/README.mdx | 19 + .../api-reference/errors/error-handling.mdx | 232 +++ .../errors/http-status-codes/README.mdx | 25 + .../horizon-specific/README.mdx | 20 + .../horizon-specific/before-history.mdx | 24 + .../horizon-specific/stale-history.mdx | 24 + .../horizon-specific/timeout.mdx | 30 + .../horizon-specific/transaction-failed.mdx | 37 + .../transaction-malformed.mdx | 32 + .../errors/http-status-codes/standard.mdx | 52 + .../horizon/api-reference/errors/response.mdx | 65 + .../errors/result-codes/README.mdx | 22 + .../operation-specific/README.mdx | 32 + .../operation-specific/account-merge.mdx | 37 + .../operation-specific/allow-trust.mdx | 37 + .../operation-specific/bump-sequence.mdx | 22 + .../operation-specific/change-trust.mdx | 34 + .../operation-specific/create-account.mdx | 34 + .../create-passive-sell-offer.mdx | 55 + .../operation-specific/manage-buy-offer.mdx | 55 + .../operation-specific/manage-data.mdx | 31 + .../operation-specific/manage-sell-offer.mdx | 55 + .../path-payment-strict-receive.mdx | 58 + .../path-payment-strict-send.mdx | 58 + .../operation-specific/payment.mdx | 49 + .../operation-specific/set-options.mdx | 46 + .../errors/result-codes/operations.mdx | 56 + .../errors/result-codes/transactions.mdx | 73 + .../api-reference/resources/README.mdx | 25 + .../resources/accounts/README.mdx | 26 + .../resources/accounts/object.mdx | 249 +++ .../api-reference/resources/assets/README.mdx | 18 + .../api-reference/resources/assets/object.mdx | 125 ++ .../resources/claimablebalances/README.mdx | 19 + .../resources/claimablebalances/object.mdx | 119 ++ .../resources/effects/README.mdx | 16 + .../api-reference/resources/effects/types.mdx | 243 +++ .../resources/ledgers/README.mdx | 23 + .../resources/ledgers/object.mdx | 115 ++ .../resources/liquiditypools/README.mdx | 21 + .../api-reference/resources/offers/README.mdx | 20 + .../api-reference/resources/offers/object.mdx | 92 + .../resources/operations/README.mdx | 21 + .../resources/operations/object/README.mdx | 74 + .../operations/object/account-merge.mdx | 61 + .../operations/object/allow-trust.mdx | 77 + .../begin-sponsoring-future-reserves.mdx | 55 + .../operations/object/bump-sequence.mdx | 57 + .../resources/operations/object/buy-offer.mdx | 100 + .../operations/object/change-trust.mdx | 80 + .../object/claim-claimable-balance.mdx | 59 + .../operations/object/create-account.mdx | 65 + .../object/create-claimable-balance.mdx | 116 ++ .../object/end-sponsoring-future-reserves.mdx | 55 + .../object/extend-footprint-ttl.mdx | 38 + .../object/invoke-host-function.mdx | 98 + .../object/liquidity-pool-deposit.mdx | 116 ++ .../object/liquidity-pool-withdraw.mdx | 92 + .../operations/object/manage-data.mdx | 61 + .../operations/object/passive-sell-offer.mdx | 101 + .../object/path-payment-strict-receive.mdx | 119 ++ .../object/path-payment-strict-send.mdx | 119 ++ .../operations/object/restore-footprint.mdx | 26 + .../operations/object/revoke-sponsorship.mdx | 79 + .../operations/object/sell-offer.mdx | 100 + .../operations/object/set-options.mdx | 87 + .../resources/payments/README.mdx | 16 + .../resources/payments/object.mdx | 77 + .../api-reference/resources/trades/README.mdx | 20 + .../api-reference/resources/trades/object.mdx | 122 ++ .../resources/transactions/README.mdx | 29 + .../resources/transactions/object.mdx | 172 ++ .../data/horizon/api-reference/sidebar.ts | 313 +++ .../api-reference/structure/README.mdx | 8 + .../structure/pagination/README.mdx | 275 +++ .../structure/pagination/page-arguments.mdx | 272 +++ .../api-reference/structure/rate-limiting.mdx | 12 + .../structure/response-format.mdx | 214 ++ .../api-reference/structure/streaming.mdx | 27 + .../horizon/api-reference/structure/xdr.mdx | 52 + .../data/horizon/horizon-providers.mdx | 40 + .../current/data/hubble/README.mdx | 32 + .../data/hubble/admin-guide/README.mdx | 10 + .../admin-guide/data-curation/README.mdx | 10 + .../data-curation/architecture.mdx | 22 + .../data-curation/getting-started.mdx | 140 ++ .../admin-guide/data-curation/overview.mdx | 15 + .../scheduling-and-orchestration/README.mdx | 10 + .../architecture.mdx | 18 + .../getting-started.mdx | 87 + .../scheduling-and-orchestration/overview.mdx | 15 + .../source-system-ingestion/README.mdx | 10 + .../source-system-ingestion/architecture.mdx | 25 + .../getting-started.mdx | 123 ++ .../source-system-ingestion/overview.mdx | 15 + .../admin-guide/visualization/README.mdx | 10 + .../visualization/getting-started.mdx | 41 + .../admin-guide/visualization/overview.mdx | 6 + .../data/hubble/analyst-guide/README.mdx | 10 + .../data/hubble/analyst-guide/connecting.mdx | 144 ++ .../end-to-end-analysis-example.mdx | 158 ++ .../analyst-guide/optimizing-queries.mdx | 231 +++ .../queries-for-horizon-like-data.mdx | 899 +++++++++ .../hubble/analyst-guide/viewing-metadata.mdx | 60 + .../data/hubble/data-catalog/README.mdx | 10 + .../data-catalog/data-dictionary/README.mdx | 10 + .../data-catalog/data-dictionary/accounts.mdx | 31 + .../data-dictionary/claimable-balances.mdx | 28 + .../data-dictionary/contract-code.mdx | 28 + .../data-dictionary/contract-data.mdx | 24 + .../enriched-history-operations.mdx | 151 ++ .../data-dictionary/history-assets.mdx | 15 + .../data-dictionary/history-effects.mdx | 160 ++ .../data-dictionary/history-ledgers.mdx | 28 + .../data-dictionary/history-operations.mdx | 137 ++ .../data-dictionary/history-trades.mdx | 34 + .../data-dictionary/history-transactions.mdx | 51 + .../data-dictionary/liquidity-pools.mdx | 28 + .../data-catalog/data-dictionary/offers.mdx | 29 + .../data-dictionary/trustlines.mdx | 26 + .../data-catalog/data-dictionary/ttl.mdx | 17 + .../data/hubble/data-catalog/data-lineage.mdx | 8 + .../data-catalog/data-model-diagram.mdx | 14 + .../current/data/requirements.mdx | 24 + .../current/data/rpc/README.mdx | 25 + .../current/data/rpc/admin-guide.mdx | 618 ++++++ .../current/data/rpc/api-reference/README.mdx | 10 + .../data/rpc/api-reference/json-rpc.mdx | 30 + .../data/rpc/api-reference/methods/README.mdx | 10 + .../rpc/api-reference/methods/getEvents.mdx | 8 + .../rpc/api-reference/methods/getFeeStats.mdx | 8 + .../rpc/api-reference/methods/getHealth.mdx | 8 + .../api-reference/methods/getLatestLedger.mdx | 8 + .../methods/getLedgerEntries.mdx | 338 ++++ .../rpc/api-reference/methods/getNetwork.mdx | 8 + .../api-reference/methods/getTransaction.mdx | 74 + .../api-reference/methods/getTransactions.mdx | 8 + .../api-reference/methods/getVersionInfo.mdx | 8 + .../api-reference/methods/sendTransaction.mdx | 136 ++ .../methods/simulateTransaction.mdx | 8 + .../data/rpc/api-reference/pagination.mdx | 28 + .../current/data/rpc/rpc-providers.mdx | 44 + .../current/learn/encyclopedia/README.mdx | 10 + .../contract-development/README.mdx | 8 + .../contract-interactions/README.mdx | 10 + .../contract-interactions/cross-contract.mdx | 25 + .../contract-interactions/overview.mdx | 39 + .../stellar-transaction.mdx | 674 +++++++ .../contract-interactions/tests.mdx | 24 + .../transaction-simulation.mdx | 35 + .../contract-lifecycle.mdx | 62 + .../environment-concepts.mdx | 69 + .../contract-development/events.mdx | 135 ++ .../contract-development/rust-dialect.mdx | 76 + .../transaction-lifecycle.mdx | 15 + .../contract-development/types/README.mdx | 10 + .../types/built-in-types.mdx | 87 + .../types/custom-types.mdx | 125 ++ .../types/fully-typed-contracts.mdx | 98 + .../learn/encyclopedia/data-format/README.mdx | 8 + .../learn/encyclopedia/data-format/xdr.mdx | 21 + .../errors-and-debugging/README.mdx | 10 + .../errors-and-debugging/debugging-errors.mdx | 104 + .../errors-and-debugging/debugging.mdx | 56 + .../errors-and-debugging/errors.mdx | 46 + .../network-configuration/README.mdx | 10 + .../network-configuration/federation.mdx | 83 + .../network-configuration/inflation.mdx | 12 + .../network-configuration/ledger-headers.mdx | 86 + .../network-passphrases.mdx | 16 + .../learn/encyclopedia/sdex/README.mdx | 8 + ...uidity-on-stellar-sdex-liquidity-pools.mdx | 620 ++++++ .../learn/encyclopedia/security/README.mdx | 8 + .../encyclopedia/security/authorization.mdx | 177 ++ .../security/securing-web-based-projects.mdx | 70 + .../security/signatures-multisig.mdx | 155 ++ .../learn/encyclopedia/storage/README.mdx | 8 + .../encyclopedia/storage/persisting-data.mdx | 98 + .../encyclopedia/storage/state-archival.mdx | 402 ++++ .../transactions-specialized/README.mdx | 8 + .../channel-accounts.mdx | 76 + .../claimable-balances.mdx | 431 ++++ .../transactions-specialized/clawbacks.mdx | 398 ++++ .../fee-bump-transactions.mdx | 129 ++ .../transactions-specialized/memos.mdx | 24 + .../path-payments.mdx | 33 + .../pooled-accounts-muxed-accounts-memos.mdx | 344 ++++ .../sponsored-reserves.mdx | 550 ++++++ .../current/learn/fundamentals/README.mdx | 10 + .../current/learn/fundamentals/anchors.mdx | 31 + .../fees-resource-limits-metering.mdx | 216 ++ .../current/learn/fundamentals/lumens.mdx | 111 ++ .../current/learn/fundamentals/networks.mdx | 105 + .../stellar-consensus-protocol.mdx | 84 + .../stellar-data-structures/README.mdx | 10 + .../stellar-data-structures/accounts.mdx | 47 + .../stellar-data-structures/assets.mdx | 98 + .../stellar-data-structures/contracts.mdx | 58 + .../stellar-data-structures/ledgers.mdx | 19 + .../stellar-ecosystem-proposals.mdx | 144 ++ .../learn/fundamentals/stellar-stack.mdx | 44 + .../fundamentals/transactions/README.mdx | 8 + .../transactions/list-of-operations.mdx | 748 +++++++ .../operations-and-transactions.mdx | 152 ++ .../transactions/transaction-lifecycle.mdx | 58 + .../current/learn/glossary.mdx | 366 ++++ .../current/learn/interactive/README.mdx | 10 + .../learn/interactive/dapps/README.mdx | 16 + .../learn/interactive/dapps/introduction.mdx | 37 + .../interactive/dapps/scaffold-soroban.mdx | 88 + .../current/learn/interactive/fca00c.mdx | 12 + .../current/learn/interactive/quest.mdx | 10 + .../current/learn/migrate/README.mdx | 10 + .../current/learn/migrate/cosmos.mdx | 8 + .../current/learn/migrate/evm/README.mdx | 10 + .../evm/introduction-to-solidity-and-rust.mdx | 37 + .../migrate/evm/smart-contract-deployment.mdx | 1293 ++++++++++++ .../solidity-and-rust-advanced-concepts.mdx | 907 +++++++++ .../migrate/evm/solidity-and-rust-basics.mdx | 643 ++++++ .../current/learn/migrate/near.mdx | 8 + .../current/learn/migrate/solana.mdx | 8 + .../current/networks/README.mdx | 31 + .../current/networks/resource-limits-fees.mdx | 54 + .../current/networks/software-versions.mdx | 1734 +++++++++++++++++ .../current/tokens/README.mdx | 83 + .../current/tokens/anatomy-of-an-asset.mdx | 31 + .../current/tokens/control-asset-access.mdx | 227 +++ .../current/tokens/how-to-issue-an-asset.mdx | 753 +++++++ .../current/tokens/publishing-asset-info.mdx | 375 ++++ .../current/tokens/quickstart.mdx | 95 + .../current/tokens/stellar-asset-contract.mdx | 114 ++ .../current/tokens/token-interface.mdx | 210 ++ .../current/tools/README.mdx | 24 + .../current/tools/developer-tools/README.mdx | 160 ++ .../current/tools/sdks/README.mdx | 10 + .../current/tools/sdks/build-your-own.mdx | 99 + .../current/tools/sdks/library.mdx | 119 ++ .../current/tools/stellar-cli.mdx | 3 + .../current/validators/README.mdx | 72 + .../current/validators/admin-guide/README.mdx | 12 + .../validators/admin-guide/advanced.mdx | 27 + .../validators/admin-guide/commands.mdx | 79 + .../validators/admin-guide/configuring.mdx | 266 +++ .../admin-guide/environment-preparation.mdx | 101 + .../validators/admin-guide/installation.mdx | 72 + .../validators/admin-guide/logging.mdx | 38 + .../validators/admin-guide/maintenance.mdx | 40 + .../validators/admin-guide/monitoring.mdx | 662 +++++++ .../admin-guide/network-upgrades.mdx | 66 + .../validators/admin-guide/prerequisites.mdx | 89 + .../publishing-history-archives.mdx | 291 +++ .../validators/admin-guide/running-node.mdx | 112 ++ .../admin-guide/soroban-settings.mdx | 172 ++ .../current/validators/tier-1-orgs.mdx | 80 + .../challenges/challenge-0-crowdfund.mdx | 357 ++++ .../dapps/challenges/challenge-1-payment.mdx | 464 +++++ .../challenges/challenge-2-liquidity-pool.mdx | 463 +++++ .../dapps/challenges/challenge-3-oracle.mdx | 540 +++++ .../docusaurus-plugin-content-pages/index.mdx | 63 + i18n/es/docusaurus-theme-classic/footer.json | 86 + i18n/es/docusaurus-theme-classic/navbar.json | 62 + 570 files changed, 65625 insertions(+) create mode 100644 i18n/es/code.json create mode 100644 i18n/es/docusaurus-plugin-content-blog/2024-01-18.mdx create mode 100644 i18n/es/docusaurus-plugin-content-blog/2024-01-26.mdx create mode 100644 i18n/es/docusaurus-plugin-content-blog/2024-02-01.mdx create mode 100644 i18n/es/docusaurus-plugin-content-blog/2024-02-09.mdx create mode 100644 i18n/es/docusaurus-plugin-content-blog/2024-02-15.mdx create mode 100644 i18n/es/docusaurus-plugin-content-blog/2024-02-22.mdx create mode 100644 i18n/es/docusaurus-plugin-content-blog/2024-02-29.mdx create mode 100644 i18n/es/docusaurus-plugin-content-blog/2024-03-07.mdx create mode 100644 i18n/es/docusaurus-plugin-content-blog/2024-03-14.mdx create mode 100644 i18n/es/docusaurus-plugin-content-blog/2024-03-21.mdx create mode 100644 i18n/es/docusaurus-plugin-content-blog/2024-03-28.mdx create mode 100644 i18n/es/docusaurus-plugin-content-blog/2024-04-04.mdx create mode 100644 i18n/es/docusaurus-plugin-content-blog/2024-04-11.mdx create mode 100644 i18n/es/docusaurus-plugin-content-blog/2024-04-18.mdx create mode 100644 i18n/es/docusaurus-plugin-content-blog/2024-04-25.mdx create mode 100644 i18n/es/docusaurus-plugin-content-blog/2024-05-02.mdx create mode 100644 i18n/es/docusaurus-plugin-content-blog/2024-05-09.mdx create mode 100644 i18n/es/docusaurus-plugin-content-blog/2024-06-13.mdx create mode 100644 i18n/es/docusaurus-plugin-content-blog/2024-06-20.mdx create mode 100644 i18n/es/docusaurus-plugin-content-blog/2024-06-27.mdx create mode 100644 i18n/es/docusaurus-plugin-content-blog/2024-07-11.mdx create mode 100644 i18n/es/docusaurus-plugin-content-blog/2024-07-18.mdx create mode 100644 i18n/es/docusaurus-plugin-content-blog/authors.yml create mode 100644 i18n/es/docusaurus-plugin-content-blog/options.json create mode 100644 i18n/es/docusaurus-plugin-content-docs-platforms/current.json create mode 100644 i18n/es/docusaurus-plugin-content-docs-platforms/current/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/architecture.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/component/observer/observer.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/component/rpc/error.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/component/rpc/request.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/component/rpc/response.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/component/rpc/rpc.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/component/security/api_key.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/component/security/jwt.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/component/security/security.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/custody-services/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/custody-services/configuration.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/custody-services/fireblocks/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/custody-services/fireblocks/configuration.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/custody-services/fireblocks/example.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/events/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/events/delivery.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/events/getting-started.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/events/integration.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/getting-started.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/overview.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/sep1/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/sep10/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/sep24/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/sep24/configuration.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/sep24/example.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/sep24/faq.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/sep24/getting-started.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/sep24/integration.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/sep24/setting-up-production-server.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/sep31/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/sep31/configuration.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/sep31/getting-started.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/sep31/integration.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/sep6/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/sep6/configuration.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/sep6/getting-started.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/sep6/integration.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/callbacks/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/callbacks/customer/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/callbacks/event/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/callbacks/fee/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/callbacks/rate/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/callbacks/sidebar.ts create mode 100644 i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/callbacks/unique-address/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/custody-server/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/custody-server/custody-transactions/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/custody-server/payments/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/custody-server/refunds/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/custody-server/sidebar.ts create mode 100644 i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/custody-server/unique-address/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/resources/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/resources/sidebar.ts create mode 100644 i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/resources/transactions/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/rpc/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/rpc/methods/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/rpc/methods/do_stellar_payment/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/rpc/methods/do_stellar_refund/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/rpc/methods/notify_amounts_updated/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/rpc/methods/notify_customer_info_updated/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/rpc/methods/notify_interactive_flow_completed/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/rpc/methods/notify_offchain_funds_available/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/rpc/methods/notify_offchain_funds_pending/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/rpc/methods/notify_offchain_funds_received/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/rpc/methods/notify_offchain_funds_sent/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/rpc/methods/notify_onchain_funds_received/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/rpc/methods/notify_onchain_funds_sent/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/rpc/methods/notify_refund_pending/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/rpc/methods/notify_refund_sent/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/rpc/methods/notify_transaction_error/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/rpc/methods/notify_transaction_expired/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/rpc/methods/notify_transaction_on_hold/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/rpc/methods/notify_transaction_recovery/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/rpc/methods/notify_trust_set/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/rpc/methods/request_customer_info_update/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/rpc/methods/request_offchain_funds/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/rpc/methods/request_onchain_funds/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/rpc/methods/request_trust/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/rpc/overview.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/rpc/sidebar.js create mode 100644 i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/admin-guide/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/admin-guide/anchor-platform-integration-points.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/admin-guide/configuring-sdp.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/admin-guide/deploy-the-sdp.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/admin-guide/design-and-architecture.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/admin-guide/getting-started.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/admin-guide/making-your-wallet-sdp-ready.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/admin-guide/migrating-to-sdp-multi-tenant.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/admin-guide/overview.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/admin-guide/secure-operation-manual.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/admin-guide/user-interface/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/admin-guide/user-interface/analytics.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/admin-guide/user-interface/dashboard-home.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/admin-guide/user-interface/disbursements.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/admin-guide/user-interface/payments.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/admin-guide/user-interface/receivers.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/admin-guide/user-interface/wallets.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/api-reference/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/api-reference/resources/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/api-reference/resources/admin/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/api-reference/resources/auth/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/api-reference/resources/disbursements/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/api-reference/resources/organization/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/api-reference/resources/payments/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/api-reference/resources/profile/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/api-reference/resources/receivers/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/api-reference/resources/registration/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/api-reference/resources/sidebar.ts create mode 100644 i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/api-reference/resources/statistics/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/api-reference/resources/users/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current.json create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/apps/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/apps/application-design-considerations.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/apps/dapp-frontend.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/apps/example-application-tutorial/account-creation.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/apps/example-application-tutorial/anchor-integration/sep1.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/apps/example-application-tutorial/anchor-integration/sep10.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/apps/example-application-tutorial/anchor-integration/sep24.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/apps/example-application-tutorial/anchor-integration/sep6.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/apps/example-application-tutorial/anchor-integration/setup.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/apps/example-application-tutorial/confirmation-modal.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/apps/example-application-tutorial/contacts-list.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/apps/example-application-tutorial/manage-trust.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/apps/example-application-tutorial/overview.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/apps/example-application-tutorial/path-payment.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/apps/example-application-tutorial/payment.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/apps/example-application-tutorial/querying-data.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/apps/ingest-sdk/ingestion-pipeline-code.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/apps/ingest-sdk/overview.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/apps/moneygram-access-integration-guide.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/apps/overview.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/apps/smart-wallets.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/apps/wallet/README.md create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/apps/wallet/component/dart/configClient.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/apps/wallet/component/dart/install.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/apps/wallet/component/header.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/apps/wallet/component/kt/configClient.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/apps/wallet/component/kt/globalSigner.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/apps/wallet/component/kt/httpConfig.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/apps/wallet/component/kt/install.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/apps/wallet/component/kt/watcher.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/apps/wallet/component/ts/allowHttpInfo.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/apps/wallet/component/ts/configClient.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/apps/wallet/component/ts/createKeypairInfo.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/apps/wallet/component/ts/globalSigner.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/apps/wallet/component/ts/install.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/apps/wallet/intro.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/apps/wallet/overview.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/apps/wallet/sep10.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/apps/wallet/sep24.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/apps/wallet/sep30.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/apps/wallet/sep38.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/apps/wallet/sep6.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/apps/wallet/stellar.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/guides/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/guides/archival/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/guides/archival/create-restoration-footprint-js.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/guides/archival/restore-contract-js.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/guides/archival/restore-data-js.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/guides/archival/test-ttl-extension.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/guides/basics/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/guides/basics/create-account.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/guides/basics/follow-received-payments.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/guides/basics/send-and-receive-payments.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/guides/cli/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/guides/cli/deploy-contract.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/guides/cli/deploy-stellar-asset-contract.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/guides/cli/extend-contract-instance.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/guides/cli/extend-contract-storage.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/guides/cli/extend-contract-wasm.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/guides/cli/install-deploy.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/guides/cli/install-wasm.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/guides/cli/restore-contract-instance.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/guides/cli/restore-contract-storage.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/guides/conventions/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/guides/conventions/analyzing-smart-contract-cost.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/guides/conventions/check-auth-tutorials.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/guides/conventions/deploy-contract.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/guides/conventions/error-enum.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/guides/conventions/install-deploy-contract-with-code.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/guides/conventions/stellar-asset-contract.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/guides/conventions/upgrading-contracts.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/guides/conventions/wasm-metadata.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/guides/conventions/work-contractspec-js.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/guides/conversions/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/guides/conversions/address-to-bytesn.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/guides/conversions/address-to-id.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/guides/conversions/id-to-address.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/guides/dapps/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/guides/dapps/docker.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/guides/dapps/initialization.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/guides/dapps/react.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/guides/events/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/guides/events/consume.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/guides/events/ingest.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/guides/events/publish.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/guides/fees/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/guides/fees/cost-analysis.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/guides/freighter/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/guides/freighter/connect-testnet.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/guides/freighter/enable-soroban-tokens.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/guides/freighter/integrate-freighter-react.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/guides/freighter/prompt-to-sign-tx.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/guides/freighter/send-token-payments.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/guides/freighter/sign-auth-entries.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/guides/freighter/sign-soroban-xdrs.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/guides/rpc/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/guides/rpc/generate-ledger-keys-python.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/guides/rpc/retrieve-contract-code-js.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/guides/rpc/retrieve-contract-code-python.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/guides/rpc/self-deploy-rpc.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/guides/rpc/use-public-rpc.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/guides/storage/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/guides/storage/choose-type.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/guides/storage/use-instance.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/guides/storage/use-persistent.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/guides/storage/use-temporary.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/guides/testing/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/guides/testing/basic-contract-tests.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/guides/testing/detecting-changes-with-test-snapshots.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/guides/testing/integration-testing-multiple-contracts.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/guides/testing/test-contract-auth.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/guides/testing/testnet-reset.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/guides/transactions/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/guides/transactions/invoke-contract-tx-sdk.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/guides/transactions/simulateTransaction-Deep-Dive.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/guides/transactions/submit-transaction-wait-js.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/smart-contracts/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/smart-contracts/example-contracts/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/smart-contracts/example-contracts/TEMPLATE.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/smart-contracts/example-contracts/alloc.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/smart-contracts/example-contracts/atomic-multi-swap.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/smart-contracts/example-contracts/atomic-swap.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/smart-contracts/example-contracts/auth.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/smart-contracts/example-contracts/cross-contract-call.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/smart-contracts/example-contracts/custom-account.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/smart-contracts/example-contracts/custom-types.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/smart-contracts/example-contracts/deployer.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/smart-contracts/example-contracts/errors.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/smart-contracts/example-contracts/events.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/smart-contracts/example-contracts/fuzzing.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/smart-contracts/example-contracts/liquidity-pool.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/smart-contracts/example-contracts/logging.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/smart-contracts/example-contracts/single-offer-sale.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/smart-contracts/example-contracts/timelock.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/smart-contracts/example-contracts/tokens.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/smart-contracts/getting-started/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/smart-contracts/getting-started/deploy-increment-contract.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/smart-contracts/getting-started/deploy-to-testnet.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/smart-contracts/getting-started/hello-world.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/smart-contracts/getting-started/setup.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/smart-contracts/getting-started/storing-data.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/build/smart-contracts/overview.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/READ_FIRST.md create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/horizon/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/horizon/admin-guide/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/horizon/admin-guide/configuring.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/horizon/admin-guide/ingestion-filtering.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/horizon/admin-guide/ingestion.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/horizon/admin-guide/installing.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/horizon/admin-guide/monitoring.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/horizon/admin-guide/overview.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/horizon/admin-guide/prerequisites.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/horizon/admin-guide/running.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/horizon/admin-guide/scaling.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/horizon/admin-guide/upgrading.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/horizon/api-reference/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/horizon/api-reference/aggregations/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/horizon/api-reference/aggregations/fee-stats/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/horizon/api-reference/aggregations/fee-stats/object.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/horizon/api-reference/aggregations/order-books/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/horizon/api-reference/aggregations/order-books/object.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/horizon/api-reference/aggregations/paths/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/horizon/api-reference/aggregations/paths/object.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/horizon/api-reference/aggregations/trade-aggregations/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/horizon/api-reference/aggregations/trade-aggregations/object.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/horizon/api-reference/errors/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/horizon/api-reference/errors/error-handling.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/horizon/api-reference/errors/http-status-codes/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/horizon/api-reference/errors/http-status-codes/horizon-specific/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/horizon/api-reference/errors/http-status-codes/horizon-specific/before-history.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/horizon/api-reference/errors/http-status-codes/horizon-specific/stale-history.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/horizon/api-reference/errors/http-status-codes/horizon-specific/timeout.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/horizon/api-reference/errors/http-status-codes/horizon-specific/transaction-failed.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/horizon/api-reference/errors/http-status-codes/horizon-specific/transaction-malformed.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/horizon/api-reference/errors/http-status-codes/standard.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/horizon/api-reference/errors/response.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/horizon/api-reference/errors/result-codes/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/horizon/api-reference/errors/result-codes/operation-specific/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/horizon/api-reference/errors/result-codes/operation-specific/account-merge.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/horizon/api-reference/errors/result-codes/operation-specific/allow-trust.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/horizon/api-reference/errors/result-codes/operation-specific/bump-sequence.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/horizon/api-reference/errors/result-codes/operation-specific/change-trust.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/horizon/api-reference/errors/result-codes/operation-specific/create-account.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/horizon/api-reference/errors/result-codes/operation-specific/create-passive-sell-offer.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/horizon/api-reference/errors/result-codes/operation-specific/manage-buy-offer.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/horizon/api-reference/errors/result-codes/operation-specific/manage-data.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/horizon/api-reference/errors/result-codes/operation-specific/manage-sell-offer.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/horizon/api-reference/errors/result-codes/operation-specific/path-payment-strict-receive.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/horizon/api-reference/errors/result-codes/operation-specific/path-payment-strict-send.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/horizon/api-reference/errors/result-codes/operation-specific/payment.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/horizon/api-reference/errors/result-codes/operation-specific/set-options.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/horizon/api-reference/errors/result-codes/operations.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/horizon/api-reference/errors/result-codes/transactions.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/horizon/api-reference/resources/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/horizon/api-reference/resources/accounts/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/horizon/api-reference/resources/accounts/object.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/horizon/api-reference/resources/assets/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/horizon/api-reference/resources/assets/object.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/horizon/api-reference/resources/claimablebalances/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/horizon/api-reference/resources/claimablebalances/object.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/horizon/api-reference/resources/effects/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/horizon/api-reference/resources/effects/types.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/horizon/api-reference/resources/ledgers/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/horizon/api-reference/resources/ledgers/object.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/horizon/api-reference/resources/liquiditypools/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/horizon/api-reference/resources/offers/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/horizon/api-reference/resources/offers/object.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/horizon/api-reference/resources/operations/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/horizon/api-reference/resources/operations/object/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/horizon/api-reference/resources/operations/object/account-merge.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/horizon/api-reference/resources/operations/object/allow-trust.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/horizon/api-reference/resources/operations/object/begin-sponsoring-future-reserves.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/horizon/api-reference/resources/operations/object/bump-sequence.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/horizon/api-reference/resources/operations/object/buy-offer.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/horizon/api-reference/resources/operations/object/change-trust.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/horizon/api-reference/resources/operations/object/claim-claimable-balance.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/horizon/api-reference/resources/operations/object/create-account.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/horizon/api-reference/resources/operations/object/create-claimable-balance.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/horizon/api-reference/resources/operations/object/end-sponsoring-future-reserves.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/horizon/api-reference/resources/operations/object/extend-footprint-ttl.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/horizon/api-reference/resources/operations/object/invoke-host-function.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/horizon/api-reference/resources/operations/object/liquidity-pool-deposit.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/horizon/api-reference/resources/operations/object/liquidity-pool-withdraw.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/horizon/api-reference/resources/operations/object/manage-data.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/horizon/api-reference/resources/operations/object/passive-sell-offer.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/horizon/api-reference/resources/operations/object/path-payment-strict-receive.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/horizon/api-reference/resources/operations/object/path-payment-strict-send.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/horizon/api-reference/resources/operations/object/restore-footprint.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/horizon/api-reference/resources/operations/object/revoke-sponsorship.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/horizon/api-reference/resources/operations/object/sell-offer.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/horizon/api-reference/resources/operations/object/set-options.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/horizon/api-reference/resources/payments/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/horizon/api-reference/resources/payments/object.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/horizon/api-reference/resources/trades/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/horizon/api-reference/resources/trades/object.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/horizon/api-reference/resources/transactions/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/horizon/api-reference/resources/transactions/object.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/horizon/api-reference/sidebar.ts create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/horizon/api-reference/structure/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/horizon/api-reference/structure/pagination/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/horizon/api-reference/structure/pagination/page-arguments.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/horizon/api-reference/structure/rate-limiting.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/horizon/api-reference/structure/response-format.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/horizon/api-reference/structure/streaming.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/horizon/api-reference/structure/xdr.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/horizon/horizon-providers.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/hubble/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/hubble/admin-guide/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/hubble/admin-guide/data-curation/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/hubble/admin-guide/data-curation/architecture.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/hubble/admin-guide/data-curation/getting-started.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/hubble/admin-guide/data-curation/overview.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/hubble/admin-guide/scheduling-and-orchestration/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/hubble/admin-guide/scheduling-and-orchestration/architecture.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/hubble/admin-guide/scheduling-and-orchestration/getting-started.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/hubble/admin-guide/scheduling-and-orchestration/overview.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/hubble/admin-guide/source-system-ingestion/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/hubble/admin-guide/source-system-ingestion/architecture.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/hubble/admin-guide/source-system-ingestion/getting-started.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/hubble/admin-guide/source-system-ingestion/overview.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/hubble/admin-guide/visualization/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/hubble/admin-guide/visualization/getting-started.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/hubble/admin-guide/visualization/overview.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/hubble/analyst-guide/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/hubble/analyst-guide/connecting.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/hubble/analyst-guide/end-to-end-analysis-example.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/hubble/analyst-guide/optimizing-queries.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/hubble/analyst-guide/queries-for-horizon-like-data.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/hubble/analyst-guide/viewing-metadata.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/hubble/data-catalog/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/hubble/data-catalog/data-dictionary/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/hubble/data-catalog/data-dictionary/accounts.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/hubble/data-catalog/data-dictionary/claimable-balances.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/hubble/data-catalog/data-dictionary/contract-code.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/hubble/data-catalog/data-dictionary/contract-data.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/hubble/data-catalog/data-dictionary/enriched-history-operations.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/hubble/data-catalog/data-dictionary/history-assets.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/hubble/data-catalog/data-dictionary/history-effects.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/hubble/data-catalog/data-dictionary/history-ledgers.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/hubble/data-catalog/data-dictionary/history-operations.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/hubble/data-catalog/data-dictionary/history-trades.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/hubble/data-catalog/data-dictionary/history-transactions.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/hubble/data-catalog/data-dictionary/liquidity-pools.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/hubble/data-catalog/data-dictionary/offers.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/hubble/data-catalog/data-dictionary/trustlines.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/hubble/data-catalog/data-dictionary/ttl.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/hubble/data-catalog/data-lineage.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/hubble/data-catalog/data-model-diagram.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/requirements.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/rpc/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/rpc/admin-guide.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/rpc/api-reference/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/rpc/api-reference/json-rpc.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/rpc/api-reference/methods/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/rpc/api-reference/methods/getEvents.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/rpc/api-reference/methods/getFeeStats.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/rpc/api-reference/methods/getHealth.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/rpc/api-reference/methods/getLatestLedger.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/rpc/api-reference/methods/getLedgerEntries.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/rpc/api-reference/methods/getNetwork.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/rpc/api-reference/methods/getTransaction.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/rpc/api-reference/methods/getTransactions.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/rpc/api-reference/methods/getVersionInfo.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/rpc/api-reference/methods/sendTransaction.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/rpc/api-reference/methods/simulateTransaction.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/rpc/api-reference/pagination.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/data/rpc/rpc-providers.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/learn/encyclopedia/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/learn/encyclopedia/contract-development/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/learn/encyclopedia/contract-development/contract-interactions/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/learn/encyclopedia/contract-development/contract-interactions/cross-contract.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/learn/encyclopedia/contract-development/contract-interactions/overview.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/learn/encyclopedia/contract-development/contract-interactions/stellar-transaction.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/learn/encyclopedia/contract-development/contract-interactions/tests.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/learn/encyclopedia/contract-development/contract-interactions/transaction-simulation.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/learn/encyclopedia/contract-development/contract-lifecycle.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/learn/encyclopedia/contract-development/environment-concepts.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/learn/encyclopedia/contract-development/events.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/learn/encyclopedia/contract-development/rust-dialect.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/learn/encyclopedia/contract-development/transaction-lifecycle.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/learn/encyclopedia/contract-development/types/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/learn/encyclopedia/contract-development/types/built-in-types.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/learn/encyclopedia/contract-development/types/custom-types.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/learn/encyclopedia/contract-development/types/fully-typed-contracts.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/learn/encyclopedia/data-format/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/learn/encyclopedia/data-format/xdr.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/learn/encyclopedia/errors-and-debugging/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/learn/encyclopedia/errors-and-debugging/debugging-errors.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/learn/encyclopedia/errors-and-debugging/debugging.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/learn/encyclopedia/errors-and-debugging/errors.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/learn/encyclopedia/network-configuration/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/learn/encyclopedia/network-configuration/federation.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/learn/encyclopedia/network-configuration/inflation.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/learn/encyclopedia/network-configuration/ledger-headers.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/learn/encyclopedia/network-configuration/network-passphrases.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/learn/encyclopedia/sdex/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/learn/encyclopedia/sdex/liquidity-on-stellar-sdex-liquidity-pools.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/learn/encyclopedia/security/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/learn/encyclopedia/security/authorization.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/learn/encyclopedia/security/securing-web-based-projects.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/learn/encyclopedia/security/signatures-multisig.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/learn/encyclopedia/storage/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/learn/encyclopedia/storage/persisting-data.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/learn/encyclopedia/storage/state-archival.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/learn/encyclopedia/transactions-specialized/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/learn/encyclopedia/transactions-specialized/channel-accounts.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/learn/encyclopedia/transactions-specialized/claimable-balances.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/learn/encyclopedia/transactions-specialized/clawbacks.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/learn/encyclopedia/transactions-specialized/fee-bump-transactions.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/learn/encyclopedia/transactions-specialized/memos.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/learn/encyclopedia/transactions-specialized/path-payments.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/learn/encyclopedia/transactions-specialized/pooled-accounts-muxed-accounts-memos.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/learn/encyclopedia/transactions-specialized/sponsored-reserves.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/learn/fundamentals/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/learn/fundamentals/anchors.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/learn/fundamentals/fees-resource-limits-metering.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/learn/fundamentals/lumens.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/learn/fundamentals/networks.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/learn/fundamentals/stellar-consensus-protocol.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/learn/fundamentals/stellar-data-structures/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/learn/fundamentals/stellar-data-structures/accounts.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/learn/fundamentals/stellar-data-structures/assets.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/learn/fundamentals/stellar-data-structures/contracts.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/learn/fundamentals/stellar-data-structures/ledgers.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/learn/fundamentals/stellar-ecosystem-proposals.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/learn/fundamentals/stellar-stack.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/learn/fundamentals/transactions/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/learn/fundamentals/transactions/list-of-operations.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/learn/fundamentals/transactions/operations-and-transactions.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/learn/fundamentals/transactions/transaction-lifecycle.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/learn/glossary.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/learn/interactive/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/learn/interactive/dapps/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/learn/interactive/dapps/introduction.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/learn/interactive/dapps/scaffold-soroban.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/learn/interactive/fca00c.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/learn/interactive/quest.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/learn/migrate/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/learn/migrate/cosmos.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/learn/migrate/evm/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/learn/migrate/evm/introduction-to-solidity-and-rust.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/learn/migrate/evm/smart-contract-deployment.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/learn/migrate/evm/solidity-and-rust-advanced-concepts.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/learn/migrate/evm/solidity-and-rust-basics.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/learn/migrate/near.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/learn/migrate/solana.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/networks/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/networks/resource-limits-fees.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/networks/software-versions.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/tokens/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/tokens/anatomy-of-an-asset.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/tokens/control-asset-access.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/tokens/how-to-issue-an-asset.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/tokens/publishing-asset-info.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/tokens/quickstart.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/tokens/stellar-asset-contract.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/tokens/token-interface.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/tools/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/tools/developer-tools/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/tools/sdks/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/tools/sdks/build-your-own.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/tools/sdks/library.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/tools/stellar-cli.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/validators/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/validators/admin-guide/README.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/validators/admin-guide/advanced.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/validators/admin-guide/commands.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/validators/admin-guide/configuring.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/validators/admin-guide/environment-preparation.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/validators/admin-guide/installation.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/validators/admin-guide/logging.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/validators/admin-guide/maintenance.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/validators/admin-guide/monitoring.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/validators/admin-guide/network-upgrades.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/validators/admin-guide/prerequisites.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/validators/admin-guide/publishing-history-archives.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/validators/admin-guide/running-node.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/validators/admin-guide/soroban-settings.mdx create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/validators/tier-1-orgs.mdx create mode 100644 i18n/es/docusaurus-plugin-content-pages/docs/learn/interactive/dapps/challenges/challenge-0-crowdfund.mdx create mode 100644 i18n/es/docusaurus-plugin-content-pages/docs/learn/interactive/dapps/challenges/challenge-1-payment.mdx create mode 100644 i18n/es/docusaurus-plugin-content-pages/docs/learn/interactive/dapps/challenges/challenge-2-liquidity-pool.mdx create mode 100644 i18n/es/docusaurus-plugin-content-pages/docs/learn/interactive/dapps/challenges/challenge-3-oracle.mdx create mode 100644 i18n/es/docusaurus-plugin-content-pages/index.mdx create mode 100644 i18n/es/docusaurus-theme-classic/footer.json create mode 100644 i18n/es/docusaurus-theme-classic/navbar.json diff --git a/i18n/es/code.json b/i18n/es/code.json new file mode 100644 index 000000000..23fce70b8 --- /dev/null +++ b/i18n/es/code.json @@ -0,0 +1,420 @@ +{ + "theme.NotFound.title": { + "message": "Page Not Found", + "description": "The title of the 404 page" + }, + "theme.NotFound.p1": { + "message": "We could not find what you were looking for.", + "description": "The first paragraph of the 404 page" + }, + "theme.NotFound.p2": { + "message": "Please contact the owner of the site that linked you to the original URL and let them know their link is broken.", + "description": "The 2nd paragraph of the 404 page" + }, + "theme.ErrorPageContent.title": { + "message": "This page crashed.", + "description": "The title of the fallback page when the page crashed" + }, + "theme.BackToTopButton.buttonAriaLabel": { + "message": "Scroll back to top", + "description": "The ARIA label for the back to top button" + }, + "theme.blog.archive.title": { + "message": "Archive", + "description": "The page & hero title of the blog archive page" + }, + "theme.blog.archive.description": { + "message": "Archive", + "description": "The page & hero description of the blog archive page" + }, + "theme.blog.paginator.navAriaLabel": { + "message": "Blog list page navigation", + "description": "The ARIA label for the blog pagination" + }, + "theme.blog.paginator.newerEntries": { + "message": "Newer Entries", + "description": "The label used to navigate to the newer blog posts page (previous page)" + }, + "theme.blog.paginator.olderEntries": { + "message": "Older Entries", + "description": "The label used to navigate to the older blog posts page (next page)" + }, + "theme.blog.post.paginator.navAriaLabel": { + "message": "Blog post page navigation", + "description": "The ARIA label for the blog posts pagination" + }, + "theme.blog.post.paginator.newerPost": { + "message": "Newer Post", + "description": "The blog post button label to navigate to the newer/previous post" + }, + "theme.blog.post.paginator.olderPost": { + "message": "Older Post", + "description": "The blog post button label to navigate to the older/next post" + }, + "theme.blog.post.plurals": { + "message": "One post|{count} posts", + "description": "Pluralized label for \"{count} posts\". Use as much plural forms (separated by \"|\") as your language support (see https://www.unicode.org/cldr/cldr-aux/charts/34/supplemental/language_plural_rules.html)" + }, + "theme.blog.tagTitle": { + "message": "{nPosts} tagged with \"{tagName}\"", + "description": "The title of the page for a blog tag" + }, + "theme.tags.tagsPageLink": { + "message": "View All Tags", + "description": "The label of the link targeting the tag list page" + }, + "theme.colorToggle.ariaLabel": { + "message": "Switch between dark and light mode (currently {mode})", + "description": "The ARIA label for the navbar color mode toggle" + }, + "theme.colorToggle.ariaLabel.mode.dark": { + "message": "dark mode", + "description": "The name for the dark color mode" + }, + "theme.colorToggle.ariaLabel.mode.light": { + "message": "light mode", + "description": "The name for the light color mode" + }, + "theme.docs.breadcrumbs.navAriaLabel": { + "message": "Breadcrumbs", + "description": "The ARIA label for the breadcrumbs" + }, + "theme.docs.DocCard.categoryDescription.plurals": { + "message": "1 item|{count} items", + "description": "The default description for a category card in the generated index about how many items this category includes" + }, + "theme.docs.paginator.navAriaLabel": { + "message": "Docs pages", + "description": "The ARIA label for the docs pagination" + }, + "theme.docs.paginator.previous": { + "message": "Previous", + "description": "The label used to navigate to the previous doc" + }, + "theme.docs.paginator.next": { + "message": "Next", + "description": "The label used to navigate to the next doc" + }, + "theme.docs.tagDocListPageTitle.nDocsTagged": { + "message": "One doc tagged|{count} docs tagged", + "description": "Pluralized label for \"{count} docs tagged\". Use as much plural forms (separated by \"|\") as your language support (see https://www.unicode.org/cldr/cldr-aux/charts/34/supplemental/language_plural_rules.html)" + }, + "theme.docs.tagDocListPageTitle": { + "message": "{nDocsTagged} with \"{tagName}\"", + "description": "The title of the page for a docs tag" + }, + "theme.docs.versionBadge.label": { + "message": "Version: {versionLabel}" + }, + "theme.docs.versions.unreleasedVersionLabel": { + "message": "This is unreleased documentation for {siteTitle} {versionLabel} version.", + "description": "The label used to tell the user that he's browsing an unreleased doc version" + }, + "theme.docs.versions.unmaintainedVersionLabel": { + "message": "This is documentation for {siteTitle} {versionLabel}, which is no longer actively maintained.", + "description": "The label used to tell the user that he's browsing an unmaintained doc version" + }, + "theme.docs.versions.latestVersionSuggestionLabel": { + "message": "For up-to-date documentation, see the {latestVersionLink} ({versionLabel}).", + "description": "The label used to tell the user to check the latest version" + }, + "theme.docs.versions.latestVersionLinkLabel": { + "message": "latest version", + "description": "The label used for the latest version suggestion link label" + }, + "theme.common.editThisPage": { + "message": "Edit this page", + "description": "The link label to edit the current page" + }, + "theme.common.headingLinkTitle": { + "message": "Direct link to {heading}", + "description": "Title for link to heading" + }, + "theme.lastUpdated.atDate": { + "message": " on {date}", + "description": "The words used to describe on which date a page has been last updated" + }, + "theme.lastUpdated.byUser": { + "message": " by {user}", + "description": "The words used to describe by who the page has been last updated" + }, + "theme.lastUpdated.lastUpdatedAtBy": { + "message": "Last updated{atDate}{byUser}", + "description": "The sentence used to display when a page has been last updated, and by who" + }, + "theme.navbar.mobileVersionsDropdown.label": { + "message": "Versions", + "description": "The label for the navbar versions dropdown on mobile view" + }, + "theme.tags.tagsListLabel": { + "message": "Tags:", + "description": "The label alongside a tag list" + }, + "theme.AnnouncementBar.closeButtonAriaLabel": { + "message": "Close", + "description": "The ARIA label for close button of announcement bar" + }, + "theme.admonition.caution": { + "message": "caution", + "description": "The default label used for the Caution admonition (:::caution)" + }, + "theme.admonition.danger": { + "message": "danger", + "description": "The default label used for the Danger admonition (:::danger)" + }, + "theme.admonition.info": { + "message": "info", + "description": "The default label used for the Info admonition (:::info)" + }, + "theme.admonition.note": { + "message": "note", + "description": "The default label used for the Note admonition (:::note)" + }, + "theme.admonition.tip": { + "message": "tip", + "description": "The default label used for the Tip admonition (:::tip)" + }, + "theme.admonition.warning": { + "message": "warning", + "description": "The default label used for the Warning admonition (:::warning)" + }, + "theme.blog.sidebar.navAriaLabel": { + "message": "Blog recent posts navigation", + "description": "The ARIA label for recent posts in the blog sidebar" + }, + "theme.CodeBlock.copied": { + "message": "Copied", + "description": "The copied button label on code blocks" + }, + "theme.CodeBlock.copyButtonAriaLabel": { + "message": "Copy code to clipboard", + "description": "The ARIA label for copy code blocks button" + }, + "theme.CodeBlock.copy": { + "message": "Copy", + "description": "The copy button label on code blocks" + }, + "theme.CodeBlock.wordWrapToggle": { + "message": "Toggle word wrap", + "description": "The title attribute for toggle word wrapping button of code block lines" + }, + "theme.DocSidebarItem.expandCategoryAriaLabel": { + "message": "Expand sidebar category '{label}'", + "description": "The ARIA label to expand the sidebar category" + }, + "theme.DocSidebarItem.collapseCategoryAriaLabel": { + "message": "Collapse sidebar category '{label}'", + "description": "The ARIA label to collapse the sidebar category" + }, + "theme.NavBar.navAriaLabel": { + "message": "Main", + "description": "The ARIA label for the main navigation" + }, + "theme.navbar.mobileLanguageDropdown.label": { + "message": "Languages", + "description": "The label for the mobile language switcher dropdown" + }, + "theme.TOCCollapsible.toggleButtonLabel": { + "message": "On this page", + "description": "The label used by the button on the collapsible TOC component" + }, + "theme.blog.post.readMore": { + "message": "Read More", + "description": "The label used in blog post item excerpts to link to full blog posts" + }, + "theme.blog.post.readMoreLabel": { + "message": "Read more about {title}", + "description": "The ARIA label for the link to full blog posts from excerpts" + }, + "theme.blog.post.readingTime.plurals": { + "message": "One min read|{readingTime} min read", + "description": "Pluralized label for \"{readingTime} min read\". Use as much plural forms (separated by \"|\") as your language support (see https://www.unicode.org/cldr/cldr-aux/charts/34/supplemental/language_plural_rules.html)" + }, + "theme.docs.breadcrumbs.home": { + "message": "Home page", + "description": "The ARIA label for the home page in the breadcrumbs" + }, + "theme.docs.sidebar.navAriaLabel": { + "message": "Docs sidebar", + "description": "The ARIA label for the sidebar navigation" + }, + "theme.docs.sidebar.collapseButtonTitle": { + "message": "Collapse sidebar", + "description": "The title attribute for collapse button of doc sidebar" + }, + "theme.docs.sidebar.collapseButtonAriaLabel": { + "message": "Collapse sidebar", + "description": "The title attribute for collapse button of doc sidebar" + }, + "theme.docs.sidebar.closeSidebarButtonAriaLabel": { + "message": "Close navigation bar", + "description": "The ARIA label for close button of mobile sidebar" + }, + "theme.navbar.mobileSidebarSecondaryMenu.backButtonLabel": { + "message": "← Back to main menu", + "description": "The label of the back button to return to main menu, inside the mobile navbar sidebar secondary menu (notably used to display the docs sidebar)" + }, + "theme.docs.sidebar.toggleSidebarButtonAriaLabel": { + "message": "Toggle navigation bar", + "description": "The ARIA label for hamburger menu button of mobile navigation" + }, + "theme.docs.sidebar.expandButtonTitle": { + "message": "Expand sidebar", + "description": "The ARIA label and title attribute for expand button of doc sidebar" + }, + "theme.docs.sidebar.expandButtonAriaLabel": { + "message": "Expand sidebar", + "description": "The ARIA label and title attribute for expand button of doc sidebar" + }, + "theme.SearchBar.seeAll": { + "message": "See all {count} results" + }, + "theme.SearchPage.documentsFound.plurals": { + "message": "One document found|{count} documents found", + "description": "Pluralized label for \"{count} documents found\". Use as much plural forms (separated by \"|\") as your language support (see https://www.unicode.org/cldr/cldr-aux/charts/34/supplemental/language_plural_rules.html)" + }, + "theme.SearchPage.existingResultsTitle": { + "message": "Search results for \"{query}\"", + "description": "The search page title for non-empty query" + }, + "theme.SearchPage.emptyResultsTitle": { + "message": "Search the documentation", + "description": "The search page title for empty query" + }, + "theme.SearchPage.inputPlaceholder": { + "message": "Type your search here", + "description": "The placeholder for search page input" + }, + "theme.SearchPage.inputLabel": { + "message": "Input Search", + "description": "The ARIA label for search page input" + }, + "theme.SearchPage.algoliaLabel": { + "message": "Search by Algolia", + "description": "The ARIA label for Algolia mention" + }, + "theme.SearchPage.noResultsText": { + "message": "No results were found", + "description": "The paragraph for empty search result" + }, + "theme.SearchPage.fetchingNewResults": { + "message": "Fetching new results...", + "description": "The paragraph for fetching new search results" + }, + "theme.SearchBar.label": { + "message": "Lable Search", + "description": "The ARIA label and placeholder for search button" + }, + "theme.SearchModal.searchBox.resetButtonTitle": { + "message": "Clear the query", + "description": "The label and ARIA label for search box reset button" + }, + "theme.SearchModal.searchBox.cancelButtonText": { + "message": "Cancel", + "description": "The label and ARIA label for search box cancel button" + }, + "theme.SearchModal.startScreen.recentSearchesTitle": { + "message": "Recent", + "description": "The title for recent searches" + }, + "theme.SearchModal.startScreen.noRecentSearchesText": { + "message": "No recent searches", + "description": "The text when no recent searches" + }, + "theme.SearchModal.startScreen.saveRecentSearchButtonTitle": { + "message": "Save this search", + "description": "The label for save recent search button" + }, + "theme.SearchModal.startScreen.removeRecentSearchButtonTitle": { + "message": "Remove this search from history", + "description": "The label for remove recent search button" + }, + "theme.SearchModal.startScreen.favoriteSearchesTitle": { + "message": "Favorite", + "description": "The title for favorite searches" + }, + "theme.SearchModal.startScreen.removeFavoriteSearchButtonTitle": { + "message": "Remove this search from favorites", + "description": "The label for remove favorite search button" + }, + "theme.SearchModal.errorScreen.titleText": { + "message": "Unable to fetch results", + "description": "The title for error screen of search modal" + }, + "theme.SearchModal.errorScreen.helpText": { + "message": "You might want to check your network connection.", + "description": "The help text for error screen of search modal" + }, + "theme.SearchModal.footer.selectText": { + "message": "to select", + "description": "The explanatory text of the action for the enter key" + }, + "theme.SearchModal.footer.selectKeyAriaLabel": { + "message": "Enter key", + "description": "The ARIA label for the Enter key button that makes the selection" + }, + "theme.SearchModal.footer.navigateText": { + "message": "to navigate", + "description": "The explanatory text of the action for the Arrow up and Arrow down key" + }, + "theme.SearchModal.footer.navigateUpKeyAriaLabel": { + "message": "Arrow up", + "description": "The ARIA label for the Arrow up key button that makes the navigation" + }, + "theme.SearchModal.footer.navigateDownKeyAriaLabel": { + "message": "Arrow down", + "description": "The ARIA label for the Arrow down key button that makes the navigation" + }, + "theme.SearchModal.footer.closeText": { + "message": "to close", + "description": "The explanatory text of the action for Escape key" + }, + "theme.SearchModal.footer.closeKeyAriaLabel": { + "message": "Escape key", + "description": "The ARIA label for the Escape key button that close the modal" + }, + "theme.SearchModal.footer.searchByText": { + "message": "Search by", + "description": "The text explain that the search is making by Algolia" + }, + "theme.SearchModal.noResultsScreen.noResultsText": { + "message": "No results for", + "description": "The text explains that there are no results for the following search" + }, + "theme.SearchModal.noResultsScreen.suggestedQueryText": { + "message": "Try searching for", + "description": "The text for the suggested query when no results are found for the following search" + }, + "theme.SearchModal.noResultsScreen.reportMissingResultsText": { + "message": "Believe this query should return results?", + "description": "The text for the question where the user thinks there are missing results" + }, + "theme.SearchModal.noResultsScreen.reportMissingResultsLinkText": { + "message": "Let us know.", + "description": "The text for the link to report missing results" + }, + "theme.SearchModal.placeholder": { + "message": "Search docs", + "description": "The placeholder of the input of the DocSearch pop-up modal" + }, + "theme.ErrorPageContent.tryAgain": { + "message": "Try again", + "description": "The label of the button to try again rendering when the React error boundary captures an error" + }, + "theme.common.skipToMainContent": { + "message": "Skip to main content", + "description": "The skip to content label used for accessibility, allowing to rapidly navigate to main content with keyboard tab/enter navigation" + }, + "theme.tags.tagsPageTitle": { + "message": "Tags", + "description": "The title of the tag list page" + }, + "theme.unlistedContent.title": { + "message": "Unlisted page", + "description": "The unlisted content banner title" + }, + "theme.unlistedContent.message": { + "message": "This page is unlisted. Search engines will not index it, and only users having a direct link can access it.", + "description": "The unlisted content banner message" + } +} \ No newline at end of file diff --git a/i18n/es/docusaurus-plugin-content-blog/2024-01-18.mdx b/i18n/es/docusaurus-plugin-content-blog/2024-01-18.mdx new file mode 100644 index 000000000..a9ba5772a --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-blog/2024-01-18.mdx @@ -0,0 +1,33 @@ +--- +title: 2024-01-18 +authors: naman +tags: + - protocol +--- + + + +[Discord agenda thread](https://discord.com/channels/897514728459468821/1196897067445010452) + +1. The need for zk-enabling encryption curves like BLS12-381. [Github thread](https://github.com/stellar/rs-soroban-env/issues/779). +2. Use cases that ecosystem is interestd in: + 1. Excellar, i.e. folks that kicked off this conversation by submitting a [PR for BLS12-381](https://github.com/stellar/rs-soroban-env/pull/1310), wants to add a DAO-controlled oracle where the elliptical curve provides the ability to add new DAO voters + 2. Zkbricks wants to build an L2 system for that enables secret state for arbitrary smart contracts + 3. Skyhitz wants to use stellar for efficient compute, cost, and scalability while using zk to prove ownership of high-value assets on another chain + 4. Use case enumeration continues in the [discord thread](https://discord.com/channels/897514728459468821/1197663875512942653). +3. Considerations for host function implementation + 1. Core devs questioned whether BLS12-381 was the right curve and also highlighted the need to determine the correct level of abstraction given there is a tradeoff between flexibility and efficiency. Lower level of abstraction will enable more flexibility but result in more hot loops in the wasm while a higher level of abstraction will be highly efficient but will restrict generality. + 2. ZkBricks thought that there is a need to directly expose pairings and group operations without any level of abstraction. The space is in active development and flexibility is needed to try out new approaches and proof systems. From the point of view of crypto agility, it would be good to expose a generic interface that supports a variety of curves in the backend. +4. Path Forward + 1. Core devs mentioned crypto curves can be experimented locally by linking rust crates, which it turns out, had failed in the past. This will be explored and fixed. + 2. ZkBricks and others will prototype locally and provide feedback. +5. What are the best practices for managing transactions in the frontend, with respect to transaction ordering. +6. Core devs confirmed that ordering is intentionally arbitrary. +7. Request for an API for current version of the environment/sdk +8. Github issue filed for the RPC to return versions of the current node. diff --git a/i18n/es/docusaurus-plugin-content-blog/2024-01-26.mdx b/i18n/es/docusaurus-plugin-content-blog/2024-01-26.mdx new file mode 100644 index 000000000..71ad695b7 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-blog/2024-01-26.mdx @@ -0,0 +1,34 @@ +--- +title: 2024-01-26 +authors: kalepail +tags: + - developer +--- + + + +[Discord agenda thread](https://discord.com/channels/897514728459468821/1199121845656486009) + +1. Plan and schedule for these meetings + 1. Protocol meetings every other Thursday at 4pm ET + 2. Developer meetings every other Friday at 1pm ET + 3. Will continue to adjust as needed +2. Fee bump bug - [announcement](https://stellar.org/blog/developers/fee-bump-bug-disclosure) | [discussion thread](https://discord.com/channels/897514728459468821/1200432249594707998/1200432306314281000) + 1. Fee sponsorship bug: unused fee is refunded to the inner tx source rather than the sponsor source. + 2. Fix in new release. Up to the ecosystem and validators to upgrade. The fix will likely be rolled out before Phase 2. + 3. Up to validators to determine if they’d like to push the v20 upgrade date to wait for the fix; or upgrade with current release. +3. TxMeta Deprecation in Horizon - [announcement](https://discord.com/channels/897514728459468821/900374272751591424/1199438109796999298) +4. Ideas around testing against ledger snapshots - [request](https://discord.com/channels/897514728459468821/1199121845656486009/1199158421254049912) + 1. Define the needs a bit more clearly + 2. Definitely something here we should be addressing to make testing against specific ledger state easier +5. How do you get a list of smart contracts? - [thread](https://discord.com/channels/897514728459468821/1199121845656486009/1199739331078803496) + 1. Observe create contract ops as ledgers close + 2. Use an [indexing service](https://developers.stellar.org/docs/tools/developer-tools#data-indexers) +6. What is the status of contracts caching support? - [question](https://discord.com/channels/897514728459468821/1199121845656486009/1200484710447587490) + 1. [response](https://discord.com/channels/897514728459468821/1199121845656486009/1200516877680644276) diff --git a/i18n/es/docusaurus-plugin-content-blog/2024-02-01.mdx b/i18n/es/docusaurus-plugin-content-blog/2024-02-01.mdx new file mode 100644 index 000000000..854325699 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-blog/2024-02-01.mdx @@ -0,0 +1,28 @@ +--- +title: 2024-02-01 +authors: naman +tags: + - protocol +--- + + + +[Discord agenda thread](https://discord.com/channels/897514728459468821/1201979721211203614) + +1. The proposal is to advance stellar-core by adding a host function to verify the secp256r1 signature, which is the most common elliptic curve used outside of the blockchain space. It is useful in connecting off-chain authentication interfaces with on-chain functionality. +2. Note that the proposal is not for a new signer type but a host function. +3. Leigh investigated adding support for the WebAuthN use case, by allowing a custom account / smart contract to sign soroban auth entries using a secp256r1-signed payload. +4. secp256r1 is supported by phones, passkeys, and enables an app to replace passwords. This is a massive benefit to user-facing applications like wallets. +5. Pros and cons of the interface: blockchains generally implement the recovery interface over the verification interface but verification is easier for developers as it reduces burden on the client and the network. +6. The WebAuthN use case requires encoding and decoding of base64 payloads and decoding JSON blobs, which is not currently supported in Soroban. +7. While there are hacky ways of accomplishing the latter, it’s not a great developer experience and final implementation is susceptible to breakages on updates. +8. It is also costly to bundle decoding with verification in guest. +9. Soroban has always led with a batteries included mindset. Keeping in line with that approach, it makes sense to further investigate and determine whether a host function makes sense for these as well. +10. Leigh’s implementation may require further evaluation of the crates used for ecdsa and p256. +11. Brief discussion around proposed process for adding of a host function by a non-core dev. diff --git a/i18n/es/docusaurus-plugin-content-blog/2024-02-09.mdx b/i18n/es/docusaurus-plugin-content-blog/2024-02-09.mdx new file mode 100644 index 000000000..76829de3a --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-blog/2024-02-09.mdx @@ -0,0 +1,21 @@ +--- +title: 2024-02-09 +authors: kalepail +tags: + - developer +--- + + + +[Discord agenda thread](https://discord.com/channels/897514728459468821/1204462856037470248) + +1. Stellar Asset List (SEP-0042) draft presentation by [OrbitLens](https://github.com/orbitlens) + 1. [SEP draft](https://github.com/orbitlens/stellar-protocol/blob/sep-0042-token-lists/ecosystem/sep-0042.md) + 2. [Discord discussion](https://discord.com/channels/897514728459468821/1162558946867953704) +2. Stellar + Soroban documentation survey + 1. [Take the survey](https://discord.com/channels/897514728459468821/1204462856037470248/1205196745877757962) diff --git a/i18n/es/docusaurus-plugin-content-blog/2024-02-15.mdx b/i18n/es/docusaurus-plugin-content-blog/2024-02-15.mdx new file mode 100644 index 000000000..a8610be80 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-blog/2024-02-15.mdx @@ -0,0 +1,44 @@ +--- +title: 2024-02-15 +authors: naman +tags: + - protocol +--- + + + +[Discord agenda thread](https://discord.com/channels/897514728459468821/1207385360116490360) + +1. The meeting was focused on the process of adding host functions, using WebAuthN as the example use case; continued from the previous meeting. +2. Discussion of remaining concerns with adding secp256r1 verification host function from previous meeting. + - What does it mean for secp256r1 to be added as a host function vs. as a signer type? + - As a host function, user can sign soroban auth entries. Need another stellar account to fund and submit tx to the chain. The latter can be done by a stellar account which may be operated by a wallet or a contract. + - \_\_check_auth is invoked when the contract being interacted with calls require_auth +3. CAP-52 was drafted to introduce encoding/decoding functions for Base64, which is needed by WebAuthN. Considerations discussed in the meeting: + - Performance: 1066 bytes that costs 1M instr to encode a 32byte hash; so the cost is very small and it’s questionable whether a host function is required. + - Interface required two functions (encode/decode) + - Implementation wise, WebAuthN requires url alphabet and padding, which decoder likely needs to support. Should we use symbols or ints? Do we need custom alphabets? + - Do we really need more encoding schemes? Isn’t XDR enough? + - Expensive auth mechanisms, i.e. webauthn, cannot be coupled with contracts with heavy business logic (which might be a lot of contracts), thus making adoption problematic. + - We should probably add building blocks to enable the ecosystem to add new use cases. +4. CAP-53 was drafted to introduce encoding/decoding functions for JSON, which is needed by WebAuthN. Considerations discussed in the meeting: + - Performance: 3.9Kb, 2.5M CPU instr. + - If the size of the input blob is unknown, execution time will increase. + - Valuable to have such a lightweight function that’ll be used in various place. + - Interface: 11 functions + - What to do with numbers and decimals? Add decimals and floats? + - We only have to extract one field for WebAuthN but what about the general case? + - The number type in JSON is decimal but soroban does not support that. How should this be handled? + - Discussion around alternative interface and implementations. +5. Core dev concerns + - Maintainability: if you add a host function, you have to maintain it forever. If there are more versions, we have to keep it around. + - Expanded surface area for security bugs. + - Should define a path where core dev is not in the implementation loop, as their schedules are packed with stability work. How to prioritize against stability work, which may get derailed due to new functionality such as what’s being currently discussed. + - Next steps: + - Core team to put together a plan for adding Base64. This is an important exercise that helps determine even more challenges of doing so. The output of this exercise may be that base64 _shouldn’t_ in fact be implemented at this point. + - Discussion around the JSON interface is to be continued. diff --git a/i18n/es/docusaurus-plugin-content-blog/2024-02-22.mdx b/i18n/es/docusaurus-plugin-content-blog/2024-02-22.mdx new file mode 100644 index 000000000..4e6fbb362 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-blog/2024-02-22.mdx @@ -0,0 +1,20 @@ +--- +title: 2024-02-22 +authors: kalepail +tags: + - developer +--- + + + +[Discord agenda thread](https://discord.com/channels/897514728459468821/1209582245824823337) + +1. Latest and greatest on the TypeScript bindings with [@chadoh](https://github.com/chadoh) +2. [Available RPC providers](/docs/data/rpc/rpc-providers) +3. Standing up a [`soroban-rpc` docker container](/docs/data/rpc/admin-guide#docker-image) +4. Installing and invoking a Stellar Asset Contract on mainnet in Phase 0 diff --git a/i18n/es/docusaurus-plugin-content-blog/2024-02-29.mdx b/i18n/es/docusaurus-plugin-content-blog/2024-02-29.mdx new file mode 100644 index 000000000..4cc4ee780 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-blog/2024-02-29.mdx @@ -0,0 +1,21 @@ +--- +title: 2024-02-29 +authors: naman +tags: + - protocol +--- + + + +[Discord agenda thread](https://discord.com/channels/897514728459468821/1212118102565855243) + +1. Tommaso (@tdep) proposed a core change to allow for extending instance and code TTL with separate values on the host environment to allow for more cost-efficient designs + a. Proposal and discussion are captured in github discussions [stellar-core#1447](https://github.com/stellar/stellar-protocol/discussions/1447) +2. Tommaso receieved feedback on the proposal as well as implementation. Since it didn't require a metering change, core devs thought it to be a quick change. +3. The ecosystem voted in favor of the proposal by upvoting the post on Github Discussions. 13 votes were [recorded](https://github.com/stellar/stellar-protocol/discussions/). +4. As next steps, a CAP will be authored to capture the proposal and put forth for approval from CAP Core Team. diff --git a/i18n/es/docusaurus-plugin-content-blog/2024-03-07.mdx b/i18n/es/docusaurus-plugin-content-blog/2024-03-07.mdx new file mode 100644 index 000000000..4864f0bb1 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-blog/2024-03-07.mdx @@ -0,0 +1,21 @@ +--- +title: 2024-03-07 +authors: kalepail +tags: + - developer +--- + + + +[Discord agenda thread](https://discord.com/channels/897514728459468821/911254664576643122/1215404506964172890) + +1. [Sorobill tool](https://github.com/kalepail/sorobill) +2. Deploying contracts and testing invocations against the unlimited [quickstart](https://github.com/stellar/quickstart). +3. Using Sorobil package as a tool to get a snapshot of all the limits the contract is touching. [Relevant blog post](https://kalepail.com/blockchain/show-me-the-bill-part-2) +4. How to measure the contract costs and what limits you are touching +5. Utilizing the Sorobil tool to decode XDR and understand failed transactions. diff --git a/i18n/es/docusaurus-plugin-content-blog/2024-03-14.mdx b/i18n/es/docusaurus-plugin-content-blog/2024-03-14.mdx new file mode 100644 index 000000000..2ad468d2b --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-blog/2024-03-14.mdx @@ -0,0 +1,25 @@ +--- +title: 2024-03-14 +authors: naman +tags: + - protocol +--- + + + +[Discord agenda thread](https://discord.com/channels/897514728459468821/1217193723612368926) + +1. CAP Core Team deliberated over the latest proposals put forth by the Stellar ecosystem to advance stellar-core. +2. Nicholas and David from the CAP Core Team listened to the following proposals and discussed the proposals with the authors. + a. CAP Core team will deliver their vote over email. +3. Proposals discussed:\ + a. [CAP-51](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0051.md): add support for secp256r1 verification; by @leigh\ + b. [CAP-53](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0053.md): create separate functions for extending the time-to-live for contract instance and contract code; by @tdep\ + c. [CAP-54](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0054.md): lower total costs by refining the Soroban cost model used for VM instantiation into multiple separate and more-accurate costs; by @graydon\ + d. [CAP-55](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0055.md): lower total costs by linking fewer host functions during VM instantiation in Soroban; by @graydon\ + e. [CAP-56](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0056.md): lower total costs by caching parsed Wasm modules within a Soroban transaction; by @graydon diff --git a/i18n/es/docusaurus-plugin-content-blog/2024-03-21.mdx b/i18n/es/docusaurus-plugin-content-blog/2024-03-21.mdx new file mode 100644 index 000000000..ed5427eda --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-blog/2024-03-21.mdx @@ -0,0 +1,22 @@ +--- +title: 2024-03-21 +authors: kalepail +tags: + - developer +--- + + + +[Discord agenda thread](https://discord.com/channels/897514728459468821/1219381314931917000) + +1. There's a discussion on a TX meta change increasing visibility and analytics within the Stellar network. (https://github.com/stellar/stellar-xdr/pull/175) +2. Read-only invocations for contracts is explained, focusing on ensuring certain functions remain read-only without side effects. (https://github.com/stellar/stellar-protocol/discussions/1454) (https://github.com/stellar/stellar-protocol/discussions/1456) (https://github.com/stellar/stellar-protocol/discussions/1464) +3. Enabling contract discovery is introduced to enhance the visibility and authenticity of smart contracts within the Stellar ecosystem. +4. The implementation of a standardized contract meta data schema is proposed to link contracts to source code and enhance contract discoverability.(https://docs.rs/soroban-sdk/latest/soroban_sdk/macro.contractmeta.html) +5. Issues related to inclusion fees in the Stellar network, highlighting the importance of monitoring fees closely and understanding the implications of surge pricing. (https://developers.stellar.org/docs/learn/fundamentals/fees-resource-limits-metering#inclusion-fee) +6. Plans are discussed for designing a new RPC endpoint to provide developers with better visibility and information on setting inclusion fees, aiming to improve transparency and decision-making regarding fee trade-offs. diff --git a/i18n/es/docusaurus-plugin-content-blog/2024-03-28.mdx b/i18n/es/docusaurus-plugin-content-blog/2024-03-28.mdx new file mode 100644 index 000000000..ebc1fce05 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-blog/2024-03-28.mdx @@ -0,0 +1,21 @@ +--- +title: 2024-03-28 +authors: naman +tags: + - protocol +--- + + + +[Agenda thread](https://github.com/stellar/stellar-protocol/discussions/1475) + +1. The Standards Working Group proposed changes to the SEP process that empower the ecosystem by making the current process more decentralized and ecosystem-friendly. +2. The process has already been used for several proposals over the last three months. +3. Esteblock from Soroswap shared their journey of participating in the proposal for Asset List ([SEP-42](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0042.md)) and implementing the proposed standard +4. Discussion continues in the proposal doc. +5. Next step is to get further ecosystem feedback then update the Github SEP repository with the updated SEP process. diff --git a/i18n/es/docusaurus-plugin-content-blog/2024-04-04.mdx b/i18n/es/docusaurus-plugin-content-blog/2024-04-04.mdx new file mode 100644 index 000000000..a2a81860a --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-blog/2024-04-04.mdx @@ -0,0 +1,34 @@ +--- +title: 2024-04-04 +authors: naman +tags: + - developer +--- + +Today's recording has two parts. The first 12 minutes are audio-only. The next 45 minutes have video as well. +Please note the slides were shared in discord chat over screensharing, due to technical difficulties. + +Part 1 (audio-only): + + + +Part 2 (video): + + + +[Discord Agenda thread](https://discord.com/channels/897514728459468821/1224408179363024918) + +1. Piyal surfaced the proposal for a [Wallet Standard](https://github.com/stellar/stellar-protocol/discussions/1467) and requested feedback. +2. Cubist, an ecosystem project, discussed CubeSigner, a low-latency API for generating keys and signing transactions inside secure hardware. +3. Stellar-based example of CubeSigner is available in the [Cubist Labs Github repository](https://github.com/cubist-labs/CubeSigner-TypeScript-SDK/tree/main/examples/stellar) +4. Cubist devs can be contacted via the Stellar discord or the [web form](https://cubist.dev/contact-form-cubesigner-hardware-backed-key-management). diff --git a/i18n/es/docusaurus-plugin-content-blog/2024-04-11.mdx b/i18n/es/docusaurus-plugin-content-blog/2024-04-11.mdx new file mode 100644 index 000000000..c6016b38d --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-blog/2024-04-11.mdx @@ -0,0 +1,22 @@ +--- +title: 2024-04-11 +authors: naman +tags: + - protocol +--- + + + +Piyal from Freighter discussed the proposal to standardize the wallet interface. Key points from the discussion are captured below. For full notes, please view the recording; and also refer to the proposal and the post on github discussions. + +1. [The draft proposal](https://github.com/stellar/stellar-protocol/blob/83191be659166e05f8df1257c6f655de9d1afe63/ecosystem/sep-0043.md) +2. [Ongoing discussion](https://github.com/stellar/stellar-protocol/discussions/1467) +3. Requiring the network passphrase might be uneeded complexity. +4. Both WalletConnect and mobile wallets likely have significant differences than the proposed interface (which is targetted at browser extension wallets); and thus likely require a separate SEP. The said SEPs should be created by teams working on wallet integration with the said platforms. +5. What is the role of the Stellar Wallet Kit in the ecosystem and how does it play with the standard itself? +6. As next steps, Piyal will incorporate the suggestions from the ecosystem into the proposal. diff --git a/i18n/es/docusaurus-plugin-content-blog/2024-04-18.mdx b/i18n/es/docusaurus-plugin-content-blog/2024-04-18.mdx new file mode 100644 index 000000000..02158dfde --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-blog/2024-04-18.mdx @@ -0,0 +1,20 @@ +--- +title: 2024-04-18 +authors: kalepail +tags: + - developer +--- + + + +[Discord agenda thread](https://discord.com/channels/897514728459468821/911254664576643122/1215404506964172890) + +1. Justin from [ortege.ai](https://www.ortege.ai/) demo'd Ortege, a data analytics platform for Stellar and Soroban. +2. Ortege lets anyone in the Stellar ecosystem create dashboards to track any and all desired metrics. Ortege's queries, widgets, and dashboards are shareable making it the perfect platform to surface +3. Justin will be releasing an AI soon and enable querying and insights via natural language. +4. All are invited to create a free account and track the success metrics for their dashboard. diff --git a/i18n/es/docusaurus-plugin-content-blog/2024-04-25.mdx b/i18n/es/docusaurus-plugin-content-blog/2024-04-25.mdx new file mode 100644 index 000000000..6e061efbc --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-blog/2024-04-25.mdx @@ -0,0 +1,25 @@ +--- +title: 2024-04-25 +authors: naman +tags: + - protocol +--- + + + +1. Garand discussed changes to the State Archival proposal based on feedback received at Meridian 2023. The proposed changes are: + +- Previously, a downstream system called the ESS (Expired State Store) would store expired entries. In the new proposal, There is no ESS. All Archived entries, as well as all information required to generate restoration proofs for those entries, is stored directly in the History Archive. +- RPC nodes can generate proofs for archived state during preflight +- Captive-core can be directly queried for archived state, meaning that RPC/Horizon instances can potentially service queries for archival state + +2. [The draft proposal](https://docs.google.com/document/d/1FAs3Yfo-o-gVqccrP29NSG8ysRvdEoyvuL7ywV4ijXI/edit#heading=h.1xwsoyifxbfm) +3. [Ongoing discussion](https://github.com/stellar/stellar-protocol/discussions/1480) +4. Snapshot size is TBD; it's a function of bucket list size as well as memory and historic demands placed on the RPC. +5. Bloom filters are the likely solution for proof of non-exitance though they come with trade-offs. They enable fast and cheap lookup but are probabilistic not deterministic. +6. Further comments are welcome. diff --git a/i18n/es/docusaurus-plugin-content-blog/2024-05-02.mdx b/i18n/es/docusaurus-plugin-content-blog/2024-05-02.mdx new file mode 100644 index 000000000..24b67a181 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-blog/2024-05-02.mdx @@ -0,0 +1,23 @@ +--- +title: 2024-05-02 +authors: naman +tags: + - developer +--- + + + +[Discord Agenda thread](https://discord.com/channels/897514728459468821/1234887262530048010/1234887262530048010) + +1. Fifo presented [Stellar Plus](https://docs.cheesecakelabs.com/stellar-plus), which is a Javascript library to simplify the Stellar and Soroban development. +2. Ecosystem members found the design for Stellar Plus composable and encompassing of all Stellar related functionality including management of assets, accounts, wasm-related operations, as well as RPC utils. +3. The links to Fifo's presentation and Stellar Plus are: + - [Miro Board showing Stellar Plus architecture](https://miro.com/app/board/uXjVKMDkMPI=/?share_link_id=643609701897) + - [Stellar Plus Repositore](https://discord.com/channels/897514728459468821/1234887262530048010/1235699608274079865) + - [Examples Repository](https://github.com/fazzatti/stellar-plus-examples) + - [Docs](https://docs.cheesecakelabs.com/stellar-plus) diff --git a/i18n/es/docusaurus-plugin-content-blog/2024-05-09.mdx b/i18n/es/docusaurus-plugin-content-blog/2024-05-09.mdx new file mode 100644 index 000000000..0c4a117ad --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-blog/2024-05-09.mdx @@ -0,0 +1,19 @@ +--- +title: 2024-05-09 +authors: naman +tags: + - developer +--- + + + +1. Tyler built a voting application using passkeys to sign the transaction, which is an implementation of the secp256r1 verification function. +2. He showed a cross-platform implementation (web and mobile) and demonstrated that passkeys are the perfect interface between web3 contracts and web2 authentication mechanisms that most end users are accostomed to. +3. Ecosystem members discussed the use of smart wallets that would use passkeys as a signer. Challenges were identified around fees requires for smart wallets, the need for a common implementation for a smart wallet, as well as how might it interface with existing password managers. +4. The voting application can be tried out at +5. Code for the demo is here diff --git a/i18n/es/docusaurus-plugin-content-blog/2024-06-13.mdx b/i18n/es/docusaurus-plugin-content-blog/2024-06-13.mdx new file mode 100644 index 000000000..3cdfcdaa8 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-blog/2024-06-13.mdx @@ -0,0 +1,25 @@ +--- +title: 2024-06-13 +authors: kalepail +tags: + - developer +--- + + + +1. Tyler created Super Peach, a web3 application that uses passkeys to sign transactions. He demonstrated how passkeys can be used in authorization flows and how they can be used to sign transactions. + - Code: https://github.com/kalepail/superpeach + - Demo: https://superpeach.vercel.app +2. Introduced `passkey-kit`. A TypeScript SDK for creating and managing Smart Wallets via passkeys (includes the actual [Smart Wallet interface](https://github.com/kalepail/passkey-kit/tree/main/contracts)) + - Code: https://github.com/kalepail/passkey-kit + - Demo: https://passkey-kit-demo.pages.dev +3. Introduced Launchtube, a service for submitting transactions onchain by covering both the transaction fee AND the sequence number. Wild! + - Code: https://github.com/kalepail/launchtube (ask in the `#passkeys` channel on Discord for a testnet token) +4. He shared his vision for pushing the passkey implementation through to becoming a [standard for the ecosystem](https://docs.google.com/document/d/1c_Wom6eK1UpC3E7VuQZfOBCLc2d5lvqAhMN7VPieMBQ/edit). + +Join the `#passkeys` channel on the Discord to continue the discussion diff --git a/i18n/es/docusaurus-plugin-content-blog/2024-06-20.mdx b/i18n/es/docusaurus-plugin-content-blog/2024-06-20.mdx new file mode 100644 index 000000000..1ad3fe0b5 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-blog/2024-06-20.mdx @@ -0,0 +1,20 @@ +--- +title: 2024-06-20 +authors: naman +tags: + - developer +--- + + + +1. [Kirckz discusses Meru](https://docs.google.com/presentation/d/1Fu4AkB0mrvOkK6UDFJHgKwCV-Ul4JRF-xPqTYJ3CQqw), a Financial services app for Freelancers and remote workers in Latin America. +2. He shares his experience integrating Meru with Blend, a liquidity protocol primitive for Stellar. +3. Kirckz shares the challenges faced during the integration and how they were overcome. +4. He shares the sdks and libraries his team used to facilitate the integration. + +Follow Meru on X (formerly Twitter) to stay updated: https://x.com/getmeru diff --git a/i18n/es/docusaurus-plugin-content-blog/2024-06-27.mdx b/i18n/es/docusaurus-plugin-content-blog/2024-06-27.mdx new file mode 100644 index 000000000..2adbca698 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-blog/2024-06-27.mdx @@ -0,0 +1,22 @@ +--- +title: 2024-06-27 +authors: naman +tags: + - developer +--- + + + +1. [Chad](https://github.com/chadoh) and [Willem](https://github.com/willemneal) from [Aha Labs](https://github.com/AhaLabs) discuss the updates to the new and improved [stellar-cli](https://github.com/stellar/stellar-cli) +2. Some highlights include the change from the name 'soroban' to 'stellar' when using the CLI tool and the addition of new commands. +3. They cover some cool functions like local network setup, account creation, and transaction signing. with the following commands: + - `stellar network container [start|logs]` + - `stellar keys [generate|fund|ls]` + - `stellar contract init` to get a whole new Soroban project + - and so much more! +4. They also discuss expected future updates including support for more Stellar operations and integration with Stellar Laboratory V2! diff --git a/i18n/es/docusaurus-plugin-content-blog/2024-07-11.mdx b/i18n/es/docusaurus-plugin-content-blog/2024-07-11.mdx new file mode 100644 index 000000000..7a2fb9a5c --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-blog/2024-07-11.mdx @@ -0,0 +1,18 @@ +--- +title: 2024-07-11 +authors: naman +tags: + - developer +--- + + + +1. SDF Data team gave a crash course in analysis of Stellar data, and covered how to access Hubble, tips for efficient querying, and how to get started with data exploration. +2. [Slides](https://docs.google.com/presentation/d/1QsCwFLFcDF4RmNIwtSSnNrUfZb0RM0kLxOOxC7ENY5M/edit#slide=id.g2cb5821e4de_1_1143) are publicly available and legible async. +3. Tips for data anlaysis are also covered in [docs](https://developers.stellar.org/docs/data/hubble/analyst-guide) +4. Share your queries and post questions in #hubble in Stellar discord, which is a dedicated channel for data-related topics. diff --git a/i18n/es/docusaurus-plugin-content-blog/2024-07-18.mdx b/i18n/es/docusaurus-plugin-content-blog/2024-07-18.mdx new file mode 100644 index 000000000..94449dba4 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-blog/2024-07-18.mdx @@ -0,0 +1,26 @@ +--- +title: 2024-07-18 +authors: naman +tags: + - developer +--- + + + +Note: the first part of the call was lost. The video posted above captures the second half of the call where various ecosystem developers shared their use cases and needs for a smart wallet on Stellar. + +1. Tyler put forward a [proposal](https://github.com/stellar/stellar-protocol/discussions/1499) for a smart wallet as a public good. Given that the native auth can be overloaded by using `__check_auth`, Stellar implementation of a smart wallet is fairly straightforward. The capability to customize the auth is already built into the core protocol. +2. See the [proposal](https://github.com/stellar/stellar-protocol/discussions/1499) here and implementation [here](https://github.com/kalepail/passkey-kit/blob/main/contracts/webauthn-wallet/src/lib.rs) +3. The proposal only uses WebAuthN-based signers i.e. passkeys. It does not use ed25519, which, perhaps it should given that ~100% of the accounts on Stellar use the scheme. It also introduces the notion of temporary and admin signers to illustrate the notion that the account can be managed by multiple signers, each with a different access policy. +4. The biggest unlock with custom auth is the ability to execute custom logic. We heard from various ecosystem members about how might they us it. + 4a. A dev is building a perpetual protocol and thought smart wallets could be used to automatically manage defi positions, which would be a significant improvement over status quo where the user has to constantly track assets to determine _when_ to execute a trade. + 4b. Folks are excited about foregoing the seed phrase for passkeys, which is especially meaningful when onboarding net new users to the blockchain. + 4c. Authorizing a cross-chain message from a different chain, especially programmatic authorization, requires an implementation of custom accounts. + 4d. Some apps have noted that users prefer not to have a wallet but simply experience the value of the app, especially games. For this, the app may assign a temprory account to the user and control access via check_auth. + 4c. Microtransactions without needing user sign is super interesting for apps as well. +5. This has been a very insightful meeting and we learnt about how the Stellar ecosystem plans to leverage smart wallet. Let's continue the conversation in discord! diff --git a/i18n/es/docusaurus-plugin-content-blog/authors.yml b/i18n/es/docusaurus-plugin-content-blog/authors.yml new file mode 100644 index 000000000..5651909b6 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-blog/authors.yml @@ -0,0 +1,10 @@ +kalepail: + name: Tyler van der Hoeven + title: Lead Developer Advocate + url: https://github.com/kalepail + image_url: https://github.com/kalepail.png +naman: + name: Naman Kumar + title: Product Manager + url: https://github.com/namankumar + image_url: https://github.com/namankumar.png diff --git a/i18n/es/docusaurus-plugin-content-blog/options.json b/i18n/es/docusaurus-plugin-content-blog/options.json new file mode 100644 index 000000000..9aeb1f875 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-blog/options.json @@ -0,0 +1,14 @@ +{ + "title": { + "message": "Meeting Notes", + "description": "The title for the blog used in SEO" + }, + "description": { + "message": "Notes and recordings from the Soroban protocol & developers meetings", + "description": "The description for the blog used in SEO" + }, + "sidebar.title": { + "message": "All meetings", + "description": "The label for the left sidebar" + } +} diff --git a/i18n/es/docusaurus-plugin-content-docs-platforms/current.json b/i18n/es/docusaurus-plugin-content-docs-platforms/current.json new file mode 100644 index 000000000..d367c5a5f --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs-platforms/current.json @@ -0,0 +1,154 @@ +{ + "version.label": { + "message": "Next", + "description": "The label for version current" + }, + "sidebar.anchor_platform.category.Anchor Platform": { + "message": "Anchor Platform", + "description": "The label for category Anchor Platform in sidebar anchor_platform" + }, + "sidebar.anchor_platform.category.Admin Guide": { + "message": "Admin Guide", + "description": "The label for category Admin Guide in sidebar anchor_platform" + }, + "sidebar.anchor_platform.category.Hosted Deposits and Withdrawals": { + "message": "Hosted Deposits and Withdrawals", + "description": "The label for category Hosted Deposits and Withdrawals in sidebar anchor_platform" + }, + "sidebar.anchor_platform.category.Programmatic Deposits and Withdrawals": { + "message": "Programmatic Deposits and Withdrawals", + "description": "The label for category Programmatic Deposits and Withdrawals in sidebar anchor_platform" + }, + "sidebar.anchor_platform.category.Cross-Border Payments": { + "message": "Cross-Border Payments", + "description": "The label for category Cross-Border Payments in sidebar anchor_platform" + }, + "sidebar.anchor_platform.category.Custody Services": { + "message": "Custody Services", + "description": "The label for category Custody Services in sidebar anchor_platform" + }, + "sidebar.anchor_platform.category.Fireblocks": { + "message": "Fireblocks", + "description": "The label for category Fireblocks in sidebar anchor_platform" + }, + "sidebar.anchor_platform.category.Event Handling": { + "message": "Event Handling", + "description": "The label for category Event Handling in sidebar anchor_platform" + }, + "sidebar.anchor_platform.category.API Reference": { + "message": "API Reference", + "description": "The label for category API Reference in sidebar anchor_platform" + }, + "sidebar.anchor_platform.category.Resources": { + "message": "Resources", + "description": "The label for category Resources in sidebar anchor_platform" + }, + "sidebar.anchor_platform.category.Transactions": { + "message": "Transactions", + "description": "The label for category Transactions in sidebar anchor_platform" + }, + "sidebar.anchor_platform.category.Callbacks": { + "message": "Callbacks", + "description": "The label for category Callbacks in sidebar anchor_platform" + }, + "sidebar.anchor_platform.category.Customers": { + "message": "Customers", + "description": "The label for category Customers in sidebar anchor_platform" + }, + "sidebar.anchor_platform.category.Events": { + "message": "Events", + "description": "The label for category Events in sidebar anchor_platform" + }, + "sidebar.anchor_platform.category.Fees": { + "message": "Fees", + "description": "The label for category Fees in sidebar anchor_platform" + }, + "sidebar.anchor_platform.category.Rates": { + "message": "Rates", + "description": "The label for category Rates in sidebar anchor_platform" + }, + "sidebar.anchor_platform.category.Unique Address": { + "message": "Unique Address", + "description": "The label for category Unique Address in sidebar anchor_platform" + }, + "sidebar.anchor_platform.category.Custody Server": { + "message": "Custody Server", + "description": "The label for category Custody Server in sidebar anchor_platform" + }, + "sidebar.anchor_platform.category.Custody Transactions": { + "message": "Custody Transactions", + "description": "The label for category Custody Transactions in sidebar anchor_platform" + }, + "sidebar.anchor_platform.category.Payments": { + "message": "Payments", + "description": "The label for category Payments in sidebar anchor_platform" + }, + "sidebar.anchor_platform.category.Refunds": { + "message": "Refunds", + "description": "The label for category Refunds in sidebar anchor_platform" + }, + "sidebar.anchor_platform.category.JSON-RPC API": { + "message": "JSON-RPC API", + "description": "The label for category JSON-RPC API in sidebar anchor_platform" + }, + "sidebar.anchor_platform.category.Methods": { + "message": "Methods", + "description": "The label for category Methods in sidebar anchor_platform" + }, + "sidebar.stellar_disbursement_platform.category.Stellar Disbursement Platform": { + "message": "Stellar Disbursement Platform", + "description": "The label for category Stellar Disbursement Platform in sidebar stellar_disbursement_platform" + }, + "sidebar.stellar_disbursement_platform.category.Admin Guide": { + "message": "Admin Guide", + "description": "The label for category Admin Guide in sidebar stellar_disbursement_platform" + }, + "sidebar.stellar_disbursement_platform.category.User Interface": { + "message": "User Interface", + "description": "The label for category User Interface in sidebar stellar_disbursement_platform" + }, + "sidebar.stellar_disbursement_platform.category.API Reference": { + "message": "API Reference", + "description": "The label for category API Reference in sidebar stellar_disbursement_platform" + }, + "sidebar.stellar_disbursement_platform.category.Resources": { + "message": "Resources", + "description": "The label for category Resources in sidebar stellar_disbursement_platform" + }, + "sidebar.stellar_disbursement_platform.category.Authentication": { + "message": "Authentication", + "description": "The label for category Authentication in sidebar stellar_disbursement_platform" + }, + "sidebar.stellar_disbursement_platform.category.Disbursements": { + "message": "Disbursements", + "description": "The label for category Disbursements in sidebar stellar_disbursement_platform" + }, + "sidebar.stellar_disbursement_platform.category.Organization": { + "message": "Organization", + "description": "The label for category Organization in sidebar stellar_disbursement_platform" + }, + "sidebar.stellar_disbursement_platform.category.Payments": { + "message": "Payments", + "description": "The label for category Payments in sidebar stellar_disbursement_platform" + }, + "sidebar.stellar_disbursement_platform.category.Profile": { + "message": "Profile", + "description": "The label for category Profile in sidebar stellar_disbursement_platform" + }, + "sidebar.stellar_disbursement_platform.category.Receivers": { + "message": "Receivers", + "description": "The label for category Receivers in sidebar stellar_disbursement_platform" + }, + "sidebar.stellar_disbursement_platform.category.Registration": { + "message": "Registration", + "description": "The label for category Registration in sidebar stellar_disbursement_platform" + }, + "sidebar.stellar_disbursement_platform.category.Statistics": { + "message": "Statistics", + "description": "The label for category Statistics in sidebar stellar_disbursement_platform" + }, + "sidebar.stellar_disbursement_platform.category.Users": { + "message": "Users", + "description": "The label for category Users in sidebar stellar_disbursement_platform" + } +} diff --git a/i18n/es/docusaurus-plugin-content-docs-platforms/current/README.mdx b/i18n/es/docusaurus-plugin-content-docs-platforms/current/README.mdx new file mode 100644 index 000000000..861fb4c13 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs-platforms/current/README.mdx @@ -0,0 +1,22 @@ +--- +title: SDF Platforms +--- + +English SDF has open-sourced some "platforms" that make it easier to accomplish certain things on the network. + +## Anchor Platform + +The Anchor Platform is a set of tools and APIs that enable developers and +businesses to build their own on and off-ramp services for the Stellar network. +It provides a standardized interface, including the implementation of several +Stellar Ecosystem Proposals (SEPs), to make it easy for businesses to integrate +with Stellar-based wallets and exchanges. + +[Learn more about the Anchor Platform API here!](/platforms/anchor-platform) + +## Stellar Disbursement Platform + +The Stellar Disbursement Platform (SDP) enables organizations to disburse bulk +payments to recipients using Stellar. + +[Learn more about the Stellar Disbursement Platform API here!](/platforms/stellar-disbursement-platform) diff --git a/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/README.mdx b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/README.mdx new file mode 100644 index 000000000..6f5587ec1 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/README.mdx @@ -0,0 +1,12 @@ +--- +title: Anchor Platform Introduction +sidebar_position: 10 +--- + +# Anchor Platform + +The Anchor Platform is a set of tools and APIs that enable developers and businesses to build their own on and off-ramp services for the Stellar network. It provides a standardized interface, including the implementation of several Stellar Ecosystem Proposals (SEPs), to make it easy for businesses to integrate with Stellar-based wallets and exchanges. + +The platform also includes features for managing assets, transactions, and user accounts, and supports a variety of deployment options, including using Docker or Kubernetes. Overall, the Anchor Platform aims to simplify the process of building and managing a Stellar-based financial service, allowing businesses to focus on providing value to their customers. + +Learn about integrating with the Anchor Platform in the [Admin Guide](./admin-guide/README.mdx) or get API information in the [API Reference](./api-reference/README.mdx). diff --git a/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/README.mdx b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/README.mdx new file mode 100644 index 000000000..d955ccbfc --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/README.mdx @@ -0,0 +1,10 @@ +--- +title: Admin Guide +sidebar_position: 10 +--- + +import DocCardList from "@theme/DocCardList"; + +All you need to know about setting up, running, and using the Anchor Platform. + + diff --git a/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/architecture.mdx b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/architecture.mdx new file mode 100644 index 000000000..0614fce0c --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/architecture.mdx @@ -0,0 +1,69 @@ +--- +title: Architecture +sidebar_position: 20 +--- + +## Architecture + +Before starting with the Anchor Platform, let's get familiar with the architecture. This section will describe the components involved and how they interact. + +### Fundamental Architecture + +The following architectural components are required for all deployments of the Anchor Platform. + +[![fundamental anchor platform architecture](/assets/anchor-platform-architecture-1.png)](/assets/anchor-platform-architecture-1.png) + +#### Client + +The client is an application, such as a wallet or remittance sender, that acts on behalf of a user and makes requests to the system. Clients make requests to the SEP server component of the Anchor Platform using sets of standards called [SEPs][seps] (Stellar Ecosystem Proposals). + +#### SEP Server + +The SEP server is a client-facing server and therefore needs to be accessible from an external network. The SEP server processes user requests and manages the state of transactions they initiate. When the SEP server needs to provide information it doesn't have to the client, such as the exchange rate for an asset pair or the KYC status of a customer, it makes synchronous [callback][callback-api] requests to the business server and returns the information in a SEP-compliant format. + +:::note + +The SEP server will never store any sensitive information, such as KYC (PII), in the database. + +::: + +#### Business Server + +The business server is a service that you (the business) must implement to connect the Anchor Platform with your internal systems. The business server responds to callback requests sent by the SEP server, such as requests for a quote, receives events sent by event service, such as notification of a received payment to your Stellar account, and provides updates to the platform server when off-chain events occur, such as the initiation of a bank transfer to a customer. + +#### Platform Server + +The platform server is an internal component. It should be hosted in a private network and should not be accessible from the Internet. This server enables the business to fetch and update the state of transactions using its [API][platform-api]. + +#### Database + +The Anchor Platform uses a PostgreSQL database to store Stellar events and entities. It is primary used to store transactions. + +### Complete Architecture + +In addition to the components described above, the Anchor Platform includes several other components that offer additional functionality. Your business can chose to which of the additional components to use, but the diagram below visualizes the architecture of the system if all components are utilized. + +[![complete anchor platform architecture](/assets/anchor-platform-architecture-2.png)](/assets/anchor-platform-architecture-2.png) + +#### Event Service + +The event service enables the Anchor Platform to send HTTP webhooks to registered clients and your business server when the state of transactions change, removing the need for clients and/or your business server to poll the Anchor Platform's APIs. It works by reading events from published to a Kafka topic by the other Anchor Platform components. [Read more][events] about using the event service. + +#### Custody Server + +The custody server connects to enterprise wallet providers, such as Fireblocks, to send and receive payments for transactions initiated via the Anchor Platform. This service is an alternative to the Stellar Observer for businesses who use one of the supported providers. In addition to the functionality offered by the Stellar Observer, the Custody Server can also facilitate outbound payments to client's Stellar accounts. If you also use the [events] service, payments to your accounts will trigger a HTTP callback made to your business server. + +If you already have an integration with your wallet provider, then this component is not required, although your business server will need to notify the Anchor Platform when a payment associated with an Anchor Platform transaction was sent to or from your Stellar accounts via the [Platform API][platform-api]. + +Currently the only supported provider is Fireblocks. + +#### Stellar Observer + +The Stellar observer, an alternative to the custody server pictured above, monitors the Stellar blockchain using Horizon, automatically detects user payments sent to the business, and updates the corresponding transactions in the Anchor Platform's database. If you also use the [events] service, payments to your accounts will trigger a HTTP callback made to your business server. + +If you already have a solution for monitor payments to your Stellar accounts, such as an integration with your exchange, Horizon, or RPC, then this component is not required, although your business server will need to notify the Anchor Platform when a payment associated with an Anchor Platform transaction was made to your one of your Stellar accounts via the [Platform API][platform-api]. + +[seps]: https://github.com/stellar/stellar-protocol/blob/master/ecosystem/README.md +[platform-api]: ../api-reference/resources/README.mdx +[callback-api]: ../api-reference/callbacks/README.mdx +[events]: ./events/README.mdx diff --git a/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/component/observer/observer.mdx b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/component/observer/observer.mdx new file mode 100644 index 000000000..133ac576f --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/component/observer/observer.mdx @@ -0,0 +1,36 @@ +Using the Payment Observer allows you to delegate this step to the Anchor Platform. To enable the Payment Observer, use the `--stellar-observer` flag in the command section of the [compose file](../../getting-started.mdx#configuration). + +The Payment Observer will track all transactions sent to the distribution account. When the transaction with the expected memo is detected in the network, the status will automatically change to `pending_anchor` and event will be the emitted (if Kafka is used). + +In order to update the transaction's statuses, the observer makes corresponding JSON-RPC requests to the platform. It should use the following URL. + + + +```bash +# dev.env +PLATFORM_API_BASE_URL=http://platform-server:8085 +``` + + + +:::caution + +The Payment Observer won't validate the amounts. It's your responsibility to verify that the amount sent by the user is correct. + +::: + +:::info + +If you already have a system that monitors payments, make sure that the logic of the system matches the description below: + +First, wait for the transaction to be included in the ledger (using an SDK). This transaction must have the expected memo and destination address (distribution account). Once this transaction has been detected and verified, notify the user that the funds have been received using the [notify_onchain_funds_received](#funds-received-1) JSON-RPC request. + +::: + +:::tip + +The Fireblocks custody service will automatically track transactions and notify the user that the funds have been received. See the [Fireblocks custody service documentation][fireblocks] for more details. + +::: + +[fireblocks]: ../../custody-services/fireblocks/README.mdx diff --git a/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/component/rpc/error.mdx b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/component/rpc/error.mdx new file mode 100644 index 000000000..b82f834dd --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/component/rpc/error.mdx @@ -0,0 +1,16 @@ +
+ +| Error code | Meaning | +| :---------- | :-------------------------------------------------------------- | +| \-32600 | The JSON sent is not a valid Request object | +| \-32601 | The method does not exist / is not available | +| \-32602 | Invalid method parameter(s) | +| \-32603 | Internal JSON-RPC error | + +
+ +:::tip + +We will also reference a `$transaction_id` variable. This is an identification of transaction that is being returned from the Anchor Platform on an withdrawal or deposit start request. You can obtain the transaction ID by connecting the test wallet to your local Anchor Platform instance. + +::: diff --git a/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/component/rpc/request.mdx b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/component/rpc/request.mdx new file mode 100644 index 000000000..9157143af --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/component/rpc/request.mdx @@ -0,0 +1,29 @@ +The Request object must contain the following attributes: + + + +- ATTRIBUTE + - DATA TYPE + - DESCRIPTION +- jsonrpc + - string + - A String specifying the version of the JSON-RPC protocol. MUST be exactly "2.0" +- method + - string + - A String containing the name of the method to be invoked. List of available methods you can see in [JSON-RPC Methods][json-rpc-methods] +- params + - object + - A Structured value that holds the parameter values, corresponding to method call, to be used during the invocation of the method +- id + - string + - An identifier established by the client. The Server will reply with the same value in the Response object + + + +:::tip + +It's possible to provide multiple updates in a single JSON-RPC request (by placing multiple JSON-RPC request objects). When an update is done in this way, all updates will be done sequentially. + +Most importantly, each JSON-RPC request is not atomic. If one update fails, all previous updates WILL be applied and all subsequent updates WILL be processed and applied as well. + +::: diff --git a/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/component/rpc/response.mdx b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/component/rpc/response.mdx new file mode 100644 index 000000000..02d808103 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/component/rpc/response.mdx @@ -0,0 +1,33 @@ +The Response is expressed as a single JSON Object, with the following attributes: + + + +- ATTRIBUTE + - DATA TYPE + - DESCRIPTION +- jsonrpc + - string + - A String specifying the version of the JSON-RPC protocol. It's set to "2.0" +- result + - object + - A Structured value that holds the updated transaction details +- id + - string + - An identifier sent by the client +- error + - object + - A Structured value that holds the error details + - id + - string + - Unique id of the transaction for which an error occurred + - code + - number + - A number that indicates the error type that occurred. Please see a list of [error codes](#error-codes) below + - message + - string + - A String providing a short description of the error + - data + - string + - A primitive or structured value that contains additional information about the error + + diff --git a/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/component/rpc/rpc.mdx b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/component/rpc/rpc.mdx new file mode 100644 index 000000000..f00b8ee7f --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/component/rpc/rpc.mdx @@ -0,0 +1,17 @@ +Before making JSON-RPC requests, let's first create a template for making a request to the Anchor Platform. + + + +```bash +# call-json-rpc.sh +#!/usr/bin/env bash + +curl localhost:8085 \ + -X POST \ + -H 'Content-Type: application/json' \ + --data "@$1" +``` + + + +This small script will make a JSON-RPC request to the Anchor Platform hosted on the default port (8085). JSON transaction data stored in the provided file will be used as body (requests must be an array). diff --git a/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/component/security/api_key.mdx b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/component/security/api_key.mdx new file mode 100644 index 000000000..f16c47f7a --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/component/security/api_key.mdx @@ -0,0 +1,14 @@ +To enable API key authentication, modify your `dev.env` file: + + + +```bash +# dev.env +PLATFORM_SERVER_AUTH_TYPE=api_key +# Will be used as API key +SECRET_PLATFORM_API_AUTH_SECRET="your API key that business server will use" +``` + + + +After it's enabled, all requests must contain a valid `X-Api-Key` header, set to the configured API key. diff --git a/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/component/security/jwt.mdx b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/component/security/jwt.mdx new file mode 100644 index 000000000..f16c47f7a --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/component/security/jwt.mdx @@ -0,0 +1,14 @@ +To enable API key authentication, modify your `dev.env` file: + + + +```bash +# dev.env +PLATFORM_SERVER_AUTH_TYPE=api_key +# Will be used as API key +SECRET_PLATFORM_API_AUTH_SECRET="your API key that business server will use" +``` + + + +After it's enabled, all requests must contain a valid `X-Api-Key` header, set to the configured API key. diff --git a/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/component/security/security.mdx b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/component/security/security.mdx new file mode 100644 index 000000000..76a3832c3 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/component/security/security.mdx @@ -0,0 +1,11 @@ +:::caution + +By default, the Platform API's endpoints such as `GET /transactions` and `GET /transactions/:id` are not protected, and are accessible by anyone who has access to the server, including wallet applications. + +::: + +:::info + +It's recommended to keep Platform server accessible only from the private network. However, you may want to add additional layer of protection via securing the API. + +::: diff --git a/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/custody-services/README.mdx b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/custody-services/README.mdx new file mode 100644 index 000000000..018055be5 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/custody-services/README.mdx @@ -0,0 +1,11 @@ +--- +title: Custody Services +sidebar_position: 80 +--- + +import DocCardList from "@theme/DocCardList"; + +Using a custody service will allow you to use an outside service to store and +manage your wallets. + + diff --git a/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/custody-services/configuration.mdx b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/custody-services/configuration.mdx new file mode 100644 index 000000000..5c540446f --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/custody-services/configuration.mdx @@ -0,0 +1,130 @@ +--- +title: Configuration +sidebar_position: 10 +--- + +import { CodeExample } from "@site/src/components/CodeExample"; + +## Custody Server Configuration + +If you want to use an external custody service to store and manage your wallets, then you need to deploy one more service - the Custody Server. + +This service also needs the `STELLAR_ANCHOR_CONFIG` that was previously mentioned. By default, the `anchor-config-default-values.yaml` config file will be used. + +Also, now you don't need to deploy the Stellar Observer since the Custody Server will be responsible for its functionality. + +Update the configuration file of the Anchor Platform with the base URL and port. + + + +```yaml +custody_server: + # The listening port of the Custody Server. + # Default value: 8086 + port: 8086 + # The base URL of the Custody Server. + # Default value: http://localhost:8086 + base_url: http://localhost:8086 +``` + + + +Configure authentication type. + + + +```yaml +custody_server: + auth: + # Type of authentication that is used when the Anchor Platform communicates with the Custody Server. + # Supported values: [none, api_key, jwt] + # Default value: none + type: none +``` + + + +If you set the `api_key` or `jwt` authentication type, then you need to add an environment variable. + + + +```bash +# dev.env +SECRET_CUSTODY_SERVER_AUTH_SECRET="Custody Server auth secret" +``` + + + +Start the Custody Server using Gradle or Docker. + + + +```bash +./gradlew service-runner:bootRun --args=--custody-server +docker run stellar-anchor-platform:latest --custody-server +``` + + + +## Anchor Platform Configuration + +Update the configuration file of the Anchor Platform with the deposit info generator type for SEP-24 and SEP-31. Also, you need to configure a trustline check, if you use JSON-RPC. + + + +```yaml +sep24: + # Used to choose how the SEP-24 deposit information (deposit address, memo and memo type) will be generated + # Supported value: [self, custody, none] + # Default value: self + deposit_info_generator_type: custody +sep31: + # Used to choose how the SEP-31 deposit information (deposit address, memo and memo type) will be generated + # Supported value: [self, custody, api] + # Default value: self + deposit_info_generator_type: custody + ## Trustline check configuration. Used only when custody integration is enabled +custody: + trustline: + ## @param: checkCronExpression + ## @type: string + ## Cron expression which defines how often a trustline check job runs. By default, a job runs every minute + # + check_cron_expression: "0 * * * * *" + ## @param: checkDuration + ## @type: integer + ## Determines how long (in MINUTES) the trustline will be checked. By default - 1 hour (60 minutes) + # + check_duration: 60 + ## @param: checkTimeoutMessage + ## @type: string + ## The message that will be added to the SEP transaction after the duration check is exceeded + # + check_timeout_message: Trustline check timed out +``` + + + +:::info + +- `self` - memo and memo type are generated in the local code, and the distribution account is used for the deposit address. +- `custody` - memo and memo type are generated through Custody API, for example Fireblocks, as well as the deposit address. +- `none` - deposit address, memo, and memo type should be provided by the business in a PATCH/JSON-RPC request. +- `api` - memo and memo type are generated through calling the anchor's GET /unique_address endpoint. + +::: + +## Kotlin Reference Server Configuration + +Update the configuration file of the Kotlin Reference Server to enable custody integration. + + + +```yaml +app: + # Flag that indicates that the custody integration is enabled and the payment will be submitted using the Custody Server. + # Default value: false + custodyEnabled: true +``` + + diff --git a/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/custody-services/fireblocks/README.mdx b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/custody-services/fireblocks/README.mdx new file mode 100644 index 000000000..948506bdc --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/custody-services/fireblocks/README.mdx @@ -0,0 +1,11 @@ +--- +title: Fireblocks +sidebar_position: 20 +--- + +import DocCardList from "@theme/DocCardList"; + +Configure [Fireblocks](https://fireblocks.io) to act as a custody service that +stores and manages your wallets. + + diff --git a/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/custody-services/fireblocks/configuration.mdx b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/custody-services/fireblocks/configuration.mdx new file mode 100644 index 000000000..46df16249 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/custody-services/fireblocks/configuration.mdx @@ -0,0 +1,68 @@ +--- +title: Configuration +sidebar_position: 10 +--- + +import { CodeExample } from "@site/src/components/CodeExample"; + +Configure Fireblocks workspace: + +1. [Configure API Co-Signer](https://support.fireblocks.io/hc/en-us/articles/4581830426268) +2. [Add API User](https://support.fireblocks.io/hc/en-us/articles/4407823826194-Adding-new-API-users) +3. [Configure Webhook URL](https://support.fireblocks.io/hc/en-us/articles/4408110107794-Configuring-Webhook-URLs) +4. [Enable One-Time Address feature](https://support.fireblocks.io/hc/en-us/articles/4409104568338) + +Update the configuration file of the Custody Server. + + + +```yaml +custody: + # Default value: none + type: fireblocks + fireblocks: + # The base URL of the Fireblocks API + # Default value: https://api.fireblocks.io + base_url: https://api.fireblocks.io + # ID of Fireblocks vault account that will be used for payments + vault_account_id: "vault_account_id" + # Fireblocks public key that is used to verify a webhook signature + public_key: "public_key" + # Mappings of fireblocks asset codes to stellar asset codes. For example: + # XLM_USDC_T_CEKS stellar:USDC:GBBD47IF6LWK7P7MDEVSCWR7DPUWV3NY3DTQEVFL4NAT4AQH3ZLLFLA5 + # XLM_TEST stellar:native + # Codes should be separated with a space and each pair of codes should be on a new line + asset_mappings: "asset_mappings" + reconciliation: + # Cron expression which defines how often the transaction reconciliation job runs. + # By default, job runs every 15 minutes. + # Default value: 0 0/15 * * * * + cron_expression: "0 0/15 * * * *" + # Determines how many times the transaction reconciliation job will attempt to update the status of the + # transaction before marking it as failed. + # Default value: 10 + max_attempts: 10 + retry_config: + # Determines how many times the Fireblocks client will attempt to send a request before marking a call as failed. + # Default value: 3 + max_attempts: 3 + # Interval between Fireblocks client call attempts (in ms) + # Default value: 1000 + delay: 1000 +``` + + + +Add the environment variables. + + + +```bash +# dev.env +# API key, that will be added to JWT token claims. JWT token will be sent in requests to Fireblocks API +SECRET_CUSTODY_FIREBLOCKS_API_KEY="Fireblocks API key" +# Secret key, that is used to sign JWT token +SECRET_CUSTODY_FIREBLOCKS_SECRET_KEY="Fireblocks secret key" +``` + + diff --git a/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/custody-services/fireblocks/example.mdx b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/custody-services/fireblocks/example.mdx new file mode 100644 index 000000000..e2ba71437 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/custody-services/fireblocks/example.mdx @@ -0,0 +1,50 @@ +--- +title: Example +sidebar_position: 10 +--- + +import { CodeExample } from "@site/src/components/CodeExample"; + +[comment]: # "Sequence diagram definitions are located in /static/definitions folder" +[comment]: # "To updated them, use https://sequencediagram.org" + +### SEP-24 deposit flow with webhook: + +- request_offchain_funds +- notify_offchain_funds_received +- do_stellar_payment +- notify_onchain_funds_sent [![sequence_diagram_sep24_deposit_webhook](/assets/sequence_diagram_sep24_deposit_webhook.png)](/assets/sequence_diagram_sep24_deposit_webhook.png) +
+ +### SEP-24 deposit flow with reconciliation job: + +- request_offchain_funds +- notify_offchain_funds_received +- do_stellar_payment +- notify_onchain_funds_sent [![sequence_diagram_sep24_deposit_job](/assets/sequence_diagram_sep24_deposit_job.png)](/assets/sequence_diagram_sep24_deposit_job.png) +
+ +### SEP-24 withdrawal flow with webhook: + +- do_stellar_payment +- notify_onchain_funds_received +- notify_offchain_funds_sent [![sequence_diagram_sep24_withdrawal_webhook](/assets/sequence_diagram_sep24_withdrawal_webhook.png)](/assets/sequence_diagram_sep24_withdrawal_webhook.png) +
+ +### SEP-24 withdrawal flow with reconciliation job: + +- request_onchain_funds +- notify_onchain_funds_received +- notify_offchain_funds_sent [![sequence_diagram_sep24_withdrawal_job](/assets/sequence_diagram_sep24_withdrawal_job.png)](/assets/sequence_diagram_sep24_withdrawal_job.png) +
+ +### SEP-31 receive flow with webhook: + +- notify_onchain_funds_received +- notify_offchain_funds_sent [![sequence_diagram_sep31_receive_webhook](/assets/sequence_diagram_sep31_receive_webhook.png)](/assets/sequence_diagram_sep31_receive_webhook.png) +
+ +### SEP-31 receive flow with reconciliation job: + +- notify_onchain_funds_received +- notify_offchain_funds_sent [![sequence_diagram_sep31_receive_job](/assets/sequence_diagram_sep31_receive_job.png)](/assets/sequence_diagram_sep31_receive_job.png) diff --git a/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/events/README.mdx b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/events/README.mdx new file mode 100644 index 000000000..43cc58bd9 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/events/README.mdx @@ -0,0 +1,10 @@ +--- +title: Event Handling +sidebar_position: 85 +--- + +import DocCardList from "@theme/DocCardList"; + +Receive transaction updates through HTTP webhook events. + + diff --git a/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/events/delivery.mdx b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/events/delivery.mdx new file mode 100644 index 000000000..d2c503d74 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/events/delivery.mdx @@ -0,0 +1,30 @@ +--- +title: Delivery Guarantees +sidebar_position: 30 +--- + +## Delivery Guarantees + +Depending on the messaging system you use, there will be different delivery guarantees. the event service uses Kafka as the messaging system, so the delivery guarantees will depend on the producer configuration and the broker configuration that you use. Depending on the number of partitions configured for the `TRANSACTION` topic, the events may be delivered out of order. + +:::caution + +Any transaction logic that depends on the order should use the transaction `status` and the `updated_at` fields to determine the order of the events. + +::: + +Next subsections will describe the delivery guarantees from the client and the business server perspective. + +### Client Delivery Guarantees + +For each client, the event service will attempt to deliver each event up to three times with an exponential backoff. If the event is not delivered after three attempts due to HTTP 4xx or 5xx errors, the event will be skipped. If the client is not reachable after three attempts, the event service will no longer attempt to deliver any events to that client. + +### Business Server Delivery Guarantees + +The event service will attempt to deliver each event to the businesss server up to three times with an exponential backoff. If the event is not delivered after three attempts due to HTTP 4xx or 5xx errors, the event will be skipped. If the business server is not reachable after three attempts, the event service will no longer attempt to deliver any events to the business server. + +:::note + +The business server delivery guarantees are the same as the client delivery guarantees. In the future, the event service will skip the events that are not delivered to clients that are not reachable. + +::: diff --git a/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/events/getting-started.mdx b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/events/getting-started.mdx new file mode 100644 index 000000000..d7c3a3832 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/events/getting-started.mdx @@ -0,0 +1,8 @@ +--- +title: Getting Started +sidebar_position: 10 +--- + +Anchor Platform provides an event service that allows your business application and client applications such as wallets to receive updates about transaction updates via HTTP webhooks without the need to poll the transactions API. + +By integrating with the event service, you or your clients will be able to receive updates about the status of transactions, including when they are submitted, completed, and failed as well as any quotes created. diff --git a/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/events/integration.mdx b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/events/integration.mdx new file mode 100644 index 000000000..0e0c1ebfe --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/events/integration.mdx @@ -0,0 +1,174 @@ +--- +title: Integration +sidebar_position: 20 +--- + +This guide will walk you through integrating with the event service to start receiving events. The event service currently only supports Apache Kafka as the backend message broker. + +It assumes familiarity with Kafka and will not cover how to set up a Kafka cluster. + +## Requirements + +Anchor Platform will send events to the `TRANSACTION` Kafka topic. The event service will consume events from this topic and send them to the appropriate endpoints. + +## Configuration + +First, the event service's Kafka producer need to be configured using the `event.queue` section of the configuration file or setting the environment variables. The following is the set of required environment variables needed to configure the event service's Kafka producer: + + + +```bash +# dev.env +EVENTS_ENABLED=true +EVENTS_QUEUE_TYPE=kafka +EVENTS_QUEUE_KAFKA_BOOTSTRAP_SERVER=localhost:9092 +``` + +```yaml +# dev.services.yaml +events: + enabled: true + queue: + type: kafka + kafka: + bootstrap_server: localhost:9092 +``` + + + +Anchor Platform allows a subset of the Kafka producer's client configuration to be set. See the [default values file][default-values-file] for more information what is available. For more information on the Kafka producer's client configuration, see the [Kafka documentation](https://kafka.apache.org/documentation/#producerconfigs). + +Next, the event processor needs to be configured in the `event_processor` section of the Anchor Platform Configuration file or setting the environment variables. + + + +```bash +# dev.env +EVENT_PROCESSOR_CLIENT_STATUS_CALLBACK_ENABLED=true +EVENT_PROCESSOR_CALLBACK_API_REQUEST_ENABLED=true +``` + +```yaml +# dev.services.yaml +event_processor: + client_status_callback: + enabled: true + callback_api_request: + enabled: true +``` + + + +This will enable the event processor to start processing events from `TRANSACTION` topic. In this example, the event processor will send events to client and business server callback endpoints. + +## Receiving Events + +The event service can be used to send events to client and business server callback endpoints. The event service will send events to these endpoints as HTTP POST requests with the event data in the request body. + +### As a Client Application + +Client applications can receive updates whenever the `status` of a SEP transaction changes. + +To receive events as a client application, you will need to expose a callback URL that the event service can send events to. The event service will send a POST request to this endpoint with the event data in the request body. + +Anchor Platform will only send events to clients listed in the client configuration. See the [client configuration documentation][clients-config] for more information. + +#### Callback Signing + +Anchor Platform signs the callback requests it sends to client applications. The signature is included in the `Signature` header of the request. The callback URL signature specification can be found in the corresponding SEP protocol specifications. + +- [SEP-0006](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0006.md#url-callback-signature) +- [SEP-0024](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0024.md#url-callback-signature) +- [SEP-0031](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0031.md#url-callback-signature) + +### As a Business Server + +In addition to SEP transaction status updates, business servers can receive events about SEP-31 quote creation or SEP-12 customer information updates. The schema of the event data will depend on the type of event being sent. Visit the [Event API documentation](../../api-reference/callbacks/post-event.api.mdx) for more information about the schema of the event data. + +To receive events as a business server, you will need to expose a callback URL that the event service can send events to. The event service will send a POST request to this endpoint with the event data in the request body. + +#### Configuration + +The event service's callback API can be configured using the `callback_api` section of the Anchor Platform configuration file or setting the environment variables. + +:::caution + +The `--event-processor` will ignore any path segments specified in `callback_api.base_url` and will instead send events to `[scheme]://[host]:[port]/event`. This is a bug, but in order not to disrupt those using the event processor, we will defer the fix of including path segments in version 3 of the Anchor Platform. + +::: + +The following is an example of how to configure the event service's callback API with JWT authentication: + + + +```bash +# dev.env + +# note `/callback` will not be used for event callbacks +# instead events will be sent to `http://localhost:8081/event` +# all other callbacks (rates, customer, etc.) will use the provided `/callback` root path +CALLBACK_API_BASE_URL=http://localhost:8081/callback +CALLBACK_API_AUTH_TYPE=jwt +CALLBACK_API_AUTH_JWT_EXPIRATION_MILLISECONDS=30000 +CALLBACK_API_AUTH_JWT_HTTP_HEADER=Authorization +SECRET_CALLBACK_API_AUTH_SECRET="a secret for signing jwts" +``` + +```yaml +# dev.services.yaml +callback_api: + base_url: http://localhost:8081/callback + auth: + type: jwt + jwt: + expiration_milliseconds: 30000 + http_header: Authorization +``` + + + +The following is an example of how to configure the event service's callback API with API key authentication: + + + +```bash +# dev.env +CALLBACK_API_BASE_URL=http://localhost:8081/callback +CALLBACK_API_AUTH_TYPE=api_key +CALLBACK_API_AUTH_API_KEY_HTTP_HEADER=X-Api-Key +SECRET_CALLBACK_API_AUTH_SECRET="your API key" +``` + +```yaml +# dev.services.yaml +callback_api: + base_url: http://localhost:8081/callback + auth: + type: api_key + api_key: + http_header: X-Api-Key +``` + + + +:::caution + +The `http_header` is not configurable as of version `2.5.2` and earlier. The default value is `Authorization` for JWT and `X-Api-Key` for API key. + +Tracking issue: https://github.com/stellar/java-stellar-anchor-sdk/issues/1272 + +::: + +This configures the event service's callback API that will be used to send events to client and business server callback endpoints. The following are the supported configuration options: + +- `base_url`: The base URL of the business server's callback endpoint. +- `secret`: The secret to be used when sending events to the business server's callback endpoint. This is used to sign the request body when JWT authentication is enabled and it is the API key when API key authentication is enabled. +- `auth`: The authentication method to be used when sending events to the business server's callback endpoint. The following are the supported authentication methods: + - `JWT`: The event service will send a JSON Web Token (JWT) in the `Authorization` header of the request. The following are the supported configuration options: + - `expiration_milliseconds`: The expiration time of the JWT in milliseconds. + - `http_header`: The header in which the JWT will be sent. + - `API_KEY`: The event service will send an API key in the `Authorization` header of the request. The following are the supported configuration options: + - `http_header`: The header in which the API key will be sent. + +[default-values-file]: https://github.com/stellar/java-stellar-anchor-sdk/blob/develop/platform/src/main/resources/config/anchor-config-default-values.yaml +[clients-config]: ../../admin-guide/sep10/README.mdx#config-with-client-attribution diff --git a/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/getting-started.mdx b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/getting-started.mdx new file mode 100644 index 000000000..ec3e692be --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/getting-started.mdx @@ -0,0 +1,382 @@ +--- +title: Getting Started +sidebar_position: 30 +--- + +## Installation + +import { CodeExample } from "@site/src/components/CodeExample"; + +The easiest way to install the Anchor Platform is to pull the [docker image][anchor-platform-image]. + + + +```bash +docker pull stellar/anchor-platform:latest +``` + + + +## Set Up the Development Environment + +In this guide we'll use [docker compose][docker-compose] for simplicity, but you can run the Anchor Platform using other tools that support docker as well, such as [minikube] or a full-blown [kubernetes] cluster. + +Let's create a minimal compose file to get started. + + + +```yaml +# docker-compose.yml +services: + sep-server: + image: stellar/anchor-platform:latest + command: --sep-server + ports: + - "8080:8080" + env_file: + - ./dev.env + volumes: + - ./config:/home + platform-server: + image: stellar/anchor-platform:latest + command: --platform-server + ports: + - "8085:8085" + env_file: + - ./dev.env + volumes: + - ./config:/home +``` + + + +The `--sep-server` option tells the Anchor Platform to make the API endpoints defined by the SEPs you've enabled via configuration available on port 8080. + +The `--platform-sever` option makes the Platform API available, which is the backend API your service(s) will use to communicate with the Anchor Platform. It will be available on port 8085 + +## Configuration + +The Anchor Platform supports two approaches for configuration: + +- using environment variables +- using a YAML configuration file + +One or a combination of both approaches can be used. Nested variables in the YAML file are expressed using underscores or dots (`_`, `.`) when using environment variables. We'll demonstrate both approaches here, but use enviroment variables exclusively in subsequent sections. See the full set of configuration options in the Anchor Platform's [default values file][ap-default-values]. + +:::info + +The Anchor Platform does not allow application secrets in the YAML configuration file. Instead, application secrets, which all have the `SECRET_` prefix, must be specified in the environment. + +::: + +Lets create the environment file specified in our docker compose file. + + + +```bash +touch dev.env +``` + + + +And if you're using a YAML configuration file, lets create that too. + + + +```bash +mkdir config +touch config/dev.services.yaml +``` + + + +You'll need to inform the Anchor Platform where it can find your config file. So lets add an environment variable for that. + + + +```bash +# dev.env +STELLAR_ANCHOR_CONFIG=/home/dev.services.yaml +``` + + + +Specify the configuration schema version in your YAML file. + + + +```yaml +# dev.services.yaml +version: 1 +``` + + + +### Changing Port of the Platform Server + +For example, let's change port of the platform server. + +Using environment variables, this is simply: + + + +```bash +# dev.env +PLATFORM_SERVER_PORT=8085 +``` + + + +Or if using YAML configuration: + + + +```yaml +# dev.services.yaml +platform_server: + port: 8085 +``` + + + +### Specify Your Service's Assets + +Lets add the assets your Anchor Platform deployment will utilize. This configuration is specified in a YAML file. If you're only using the Anchor Platform for hosting a SEP-1 stellar.toml file or for running SEP-10 Stellar Authentication, you can skip this step. + + + +```bash +touch config/dev.assets.yaml +``` + + + +In this guide we'll build anchor services for Circle's USDC on Stellar's test network. Update the above values based on the assets you'll be issuing. Make sure to specify the testnet `issuer` in your development file, and create your own `distribution_account` using a tool like [Stellar Lab][stellar-lab]. The `distribution_account` will be used by your clients as the destination account for payments to your service. + + + +```yaml +# dev.assets.yaml +assets: + - schema: stellar + code: USDC + issuer: GBBD47IF6LWK7P7MDEVSCWR7DPUWV3NY3DTQEVFL4NAT4AQH3ZLLFLA5 + distribution_account: GBLSAHONJRODSFTLOV225NZR4LHICH63RIFQTQN37L5CRTR2IMQ5UEK7 + significant_decimals: 2 +``` + + + +This file needs to be referenced in our configuration so the Anchor Platform can find it. + +Using environment variables: + + + +```bash +# dev.env +ASSETS_TYPE=file +ASSETS_VALUE=/home/dev.assets.yaml +``` + + + +Using a YAML file: + + + +```yaml +# dev.services.yaml +assets: + type: file + value: /home/dev.assets.yaml +``` + + + +### Add Data Persistence + +The Anchor Platform supports [PostgreSQL][postgresql] and [Aurora PostgreSQL][aurora-postgresql] for use in production, but also supports [H2][h2] or [SQLite][sqlite] for use in development. For managing migrations, the Anchor Platform uses [Flyway][flyway]. The latest version of PostgreSQL supported by Flyway is PostgreSQL 14. + +Before we move forward, let's add a database to our development environment so the transactions we initiate persist after stopping the service. + +A database is only needed if using the Anchor Platform to facilitate transactions. + + + +```yaml +# docker-compose.yml +version: "3.8" +services: + sep-server: + image: stellar/anchor-platform:latest + command: --sep-server + env_file: + - ./dev.env + volumes: + - ./config:/home + ports: + - "8080:8080" + depends_on: + - db + platform-server: + image: stellar/anchor-platform:latest + command: --platform-server + env_file: + - ./dev.env + volumes: + - ./config:/home + ports: + - "8085:8085" + depends_on: + - db + db: + image: postgres:14 + ports: + - "5432:5432" + env_file: + - ./dev.env + volumes: + - ./init.sql:/docker-entrypoint-initdb.d/init.sql +``` + + + +Now let's update our environment so the platform server can connect to the database server. + + + +```bash +# dev.env +DATA_TYPE=postgres +DATA_SERVER=db +DATA_DATABASE=platform +DATA_FLYWAY_ENABLED=true + +SECRET_DATA_USERNAME=postgres +SECRET_DATA_PASSWORD=password + +POSTGRES_USER=postgres +POSTGRES_PASSWORD=password +``` + + + +If you're using YAML configuration instead, the `POSTGRES_` environment variables should always be in the environment, as they're for your database server, not the Anchor Platform. The secrets must also be specified in environment. + + + +```yaml +# dev.services.yaml +data: + type: postgres + server: db + database: platform + flyway_enabled: true +``` + + + +We have to create the `platform` database before the platform server can connect to it, so let's make a script to create our database. + + + +```bash +touch init.sql +``` + + + + + +```sql +-- init.sql +CREATE DATABASE platform; +``` + + + +Try to run the platform server in addition to the database. + + + +```bash +docker compose up +``` + + + +You should see the logs reporting a successful connection to the postgres database. + +### Configure Platform API Authentication + +To facilitate cross-border payments or deposit & withdrawal transactions, your business will need to fetch and update transaction records from the Anchor Platform's internal API. Currently, the `--sep-server` option makes public SEP APIs, while internal Platform API available on the Platform server, started by `--platform-server` option. Business should make Platform Server accessible only in the internal network, however it's possible to add authentication for accessing the internal Platform API. + +Add the following environment variables. + + + +```bash +# dev.env +PLATFORM_API_BASE_URL=http://platform-server:8085 +PLATFORM_API_AUTH_TYPE=jwt +SECRET_PLATFORM_API_AUTH_SECRET=[your jwt encryption key] +``` + + + +When making requests to the Platform API, add a JWT signed by the secret defined in your environment to the `Authorization` header as a bearer token. + +`PLATFORM_API_BASE_URL` uses `platform` instead of `localhost` as the host because you'll be making requests to the Platform API within the local network created by docker compose. When configuring your service in a staging or production environment, make sure to update your service urls. + +### Passing JVM flags + +Anchor Platform uses JVM to run. Sometimes, it's desired to change JVM flags to run the service. To do so, set environmental variable `JVM_FLAGS` to appropriate value + +```bash +# dev.env +JVM_FLAGS="-Xms256m -Xmx2048m" +``` + +:::tip + +If you need to pass environment variable from your machine to container, you should use `environment` compose option to set variables instead. Here's an example of using keystore from your local machine in the container: + +```yaml +# docker-compose.yml +version: "3.8" +services: + sep-server: + image: stellar/anchor-platform:latest + command: --sep-server + env_file: + - ./dev.env + environment: + JVM_FLAGS: -Djavax.net.ssl.trustStore=/keystore.jks -Djavax.net.ssl.trustStorePassword=${KEYSTORE_PASSWORD} + volumes: + - ${KEYSTORE_LOCATION}:/keystore.jks +# ... +``` + +Where `KEYSTORE_LOCATION` is local keystore location and `KEYSTORE_PASSWORD` is local keystore password. ::: + +[sep-1]: https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0001.md +[sep-9]: https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0009.md +[sep-24]: https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0024.md +[sep-38]: https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0038.md +[sep24-get-info]: https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0024.md#info +[anchor-platform-image]: https://hub.docker.com/r/stellar/anchor-platform +[docker-compose]: https://docs.docker.com/compose/ +[minikube]: https://minikube.sigs.k8s.io/docs/ +[kubernetes]: https://kubernetes.io/ +[nginx]: https://www.nginx.com/ +[ap-default-values]: https://github.com/stellar/java-stellar-anchor-sdk/blob/develop/platform/src/main/resources/config/anchor-config-default-values.yaml +[stellar-demo-wallet]: https://demo-wallet.stellar.org +[stellar-lab]: https://laboratory.stellar.org/ +[postgresql]: https://www.postgresql.org/ +[aurora-postgresql]: https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.AuroraPostgreSQL.html +[h2]: https://www.h2database.com/html/main.html +[sqlite]: https://www.sqlite.org/index.html +[flyway]: https://documentation.red-gate.com/fd/welcome-to-flyway-184127914.html +[sep-24-ref-ui]: https://github.com/stellar/sep24-reference-ui +[sep-24-ref]: https://github.com/stellar/java-stellar-anchor-sdk/tree/develop/kotlin-reference-server diff --git a/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/overview.mdx b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/overview.mdx new file mode 100644 index 000000000..6a26ff8f0 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/overview.mdx @@ -0,0 +1,36 @@ +--- +title: Overview +sidebar_position: 10 +--- + +The Anchor Platform is the easiest and fastest way to deploy [anchor services](../../../docs/learn/fundamentals/anchors) compatible with [Stellar Ecosystem Proposals (SEPs)](https://github.com/stellar/stellar-protocol/tree/master/ecosystem). + +The goal of the Anchor Platform is to handle all Stellar-specific functionality and requirements for running an anchor, allowing businesses to focus on the core business logic necessary to provide these services. + +The Anchor Platform accomplishes this by implementing the ecosystem's standardized APIs (SEPs) for wallets, exchanges, and other applications to consume, while offering a set of backend APIs for businesses to provide information specific to them, such as transaction fees, exchange rates, and off-chain transaction statuses. + +Below is a list of SEPs currently supported: + +- [SEP-1][sep-1]: [Stellar Info File][sep1-ap] +- [SEP-6][sep-6]: [Programmatic Deposit and Withdrawal][sep6-ap] +- [SEP-10][sep-10]: [Stellar Authentication][sep10-ap] +- [SEP-12][sep-12]: KYC API +- [SEP-24][sep-24]: [Hosted Deposit and Withdrawal][sep24-ap] +- [SEP-31][sep-31]: [Cross-Border Payments API][sep31-ap] +- [SEP-38][sep-38]: Anchor RFQ API + +The documentation for the Anchor Platform is a work in progress. Developers are welcome to dive into the code and existing documentation on the [GitHub repository][anchor-platform-github], or if you're looking to build an on & off-ramp service compatible with SEP-24, see our [getting started guide][sep24-ap]. + +[sep-1]: https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0001.md +[sep-6]: https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0006.md +[sep-10]: https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0010.md +[sep-12]: https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0012.md +[sep-24]: https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0024.md +[sep-31]: https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0031.md +[sep-38]: https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0038.md +[anchor-platform-github]: https://github.com/stellar/java-stellar-anchor-sdk +[sep1-ap]: ./sep1/README.mdx +[sep6-ap]: ./sep6/README.mdx +[sep10-ap]: ./sep10/README.mdx +[sep24-ap]: ./sep24/README.mdx +[sep31-ap]: ./sep31/README.mdx diff --git a/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/sep1/README.mdx b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/sep1/README.mdx new file mode 100644 index 000000000..72834e2a2 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/sep1/README.mdx @@ -0,0 +1,66 @@ +--- +title: Stellar Info File +sidebar_position: 40 +--- + +import { CodeExample } from "@site/src/components/CodeExample"; + +Let's enable applications to learn more about your service by hosting a `stellar.toml` file at a standardized URL path. This file allows applications to find information about your business, the assets your services utilize, as well as the root URL paths for these services. We can host this file using the Anchor Platform. + +Let's create a file called `dev.stellar.toml` file using the contents below as a starting point. For the full set of attributes, see the [SEP-1 specification][sep-1]. + + + +```toml +# dev.stellar.toml +ACCOUNTS = ["add your public keys for your distribution accounts here"] +SIGNING_KEY = "add your signing key here" +NETWORK_PASSPHRASE = "Test SDF Network ; September 2015" + +[DOCUMENTATION] +ORG_NAME = "Your organization" +ORG_URL = "Your website" +ORG_DESCRIPTION = "A description of your organization" +``` + + + +Note that you'll need to create another file for your production deployment that uses the public network's passphrase, your production service URLs, your Mainnet distribution accounts and signing key, as well as the Mainnet issuing accounts of the assets your service utilizes. + +In your `dev.env` file, specify the following. + + + +```bash +# dev.env +SEP1_ENABLED=true +SEP1_TOML_TYPE=file +SEP1_TOML_VALUE=/home/dev.stellar.toml +``` + + + +This will tell the Anchor Platform that it should host the file specified by `SEP1_TOML_VALUE` at `./well-known/stellar.toml`. + +Alternatively, your `stellar.toml` file could be hosted using a proper static file server like [nginx]. As long as your info file includes the appropriate URLs pointing to the Anchor Platform, this will work just fine. + +[sep-1]: https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0001.md +[sep-9]: https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0009.md +[sep-24]: https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0024.md +[sep-38]: https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0038.md +[sep24-get-info]: https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0024.md#info +[anchor-platform-image]: https://hub.docker.com/r/stellar/anchor-platform +[docker-compose]: https://docs.docker.com/compose/ +[minikube]: https://minikube.sigs.k8s.io/docs/ +[kubernetes]: https://kubernetes.io/ +[nginx]: https://www.nginx.com/ +[ap-default-values]: https://github.com/stellar/java-stellar-anchor-sdk/blob/develop/platform/src/main/resources/config/anchor-config-default-values.yaml +[stellar-demo-wallet]: https://demo-wallet.stellar.org +[stellar-lab]: https://laboratory.stellar.org/ +[postgresql]: https://www.postgresql.org/ +[aurora-postgresql]: https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.AuroraPostgreSQL.html +[h2]: https://www.h2database.com/html/main.html +[sqlite]: https://www.sqlite.org/index.html +[flyway]: https://documentation.red-gate.com/fd/welcome-to-flyway-184127914.html +[sep-24-ref-ui]: https://github.com/stellar/sep24-reference-ui +[sep-24-ref]: https://github.com/stellar/java-stellar-anchor-sdk/tree/develop/kotlin-reference-server diff --git a/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/sep10/README.mdx b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/sep10/README.mdx new file mode 100644 index 000000000..485e404be --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/sep10/README.mdx @@ -0,0 +1,143 @@ +--- +title: Stellar Authentication +sidebar_position: 50 +--- + +import { CodeExample } from "@site/src/components/CodeExample"; + +## Enable Stellar Authentication + +Stellar-based wallet applications create authenticated sessions with Stellar anchors by proving they, or their users, have sufficient control over a Stellar account. Once authenticated, the wallet application uses a session token provided by the anchor in subsequent requests to the anchor's standardized services. + +The Anchor Platform supports this form of authentication with minimal configuration from the business. + + + +```bash +# dev.env +SEP10_ENABLED=true +SEP10_HOME_DOMAIN=localhost:8080 +SECRET_SEP10_SIGNING_SEED="a Stellar private key" +SECRET_SEP10_JWT_SECRET="a secret encryption key" +``` + + + +`SEP_10_HOME_DOMAIN` is the `home_domain` property used by [sep-10]. The configuration value must be equal to the host of the toml file. If you are hosting toml file via the Platform, (`SEP1_ENABLED` is set to `true`), toml file will be hosted on the SEP server. + +`SECRET_SEP10_SIGNING_SEED` is the private key to the public key you've specified as the `SIGNING_KEY` in your `stellar.toml` file. It will be used to sign authentication challenges presented to wallet applications, providing that you are in possession of the `SIGNING_KEY`. Wallets will check for this signature before signing and sending back the authentication challenge. + +`SECRET_SEP10_JWT_SECRET` is the encryption key that will be used to sign and verify the authentication tokens you issue to wallet applications after they or their users have proven control of their Stellar account. + +:::info + +By default, the Anchor Platform allows anyone with a Stellar account to authenticate with your services. If you'd like to only allow users of a particular wallet application to authenticate, or want to disallow specific users from authenticating, use the following environment variables. This is an optional feature and should only be added if it is a business requirement. + +::: + +## Config With Client Attribution + +`SEP10_CLIENT_ATTRIBUTION_REQUIRED` informs the Anchor Platform whether it should allow users of noncustodial wallets to authenticate without the wallet also identifying itself. + +`CLIENTS` is the list of outside wallet servers or clients for the Anchor server to safely communicate with. + + + +```bash +# dev.env +SEP10_CLIENT_ATTRIBUTION_REQUIRED=true +``` + + + + + +```yaml +clients: + # Each item in the list may contain the following fields: + # - name: (required) the name of the client + # - type: (required) `custodial` or `noncustodial` + # + # If the type is `custodial`, + # - signing_keys: (required) the custodial SEP-10 signing key of the client. + # - callback_url: (optional) the URL of the client's callback API endpoint. + # - allow_any_destination: (optional) default to false. If set to true, allows any destination for deposits. + # - destination_accounts: (optional) list of accounts allowed to be used for the deposit. If allows_any_destinations set to true, this configuration option is ignored. + # + # If the type is `noncustodial`, + # - domains: (required) the domains of the client. + # - callback_url: (optional) the URL of the client's callback API endpoint + + # custodial client + - name: custodial-client1 + type: custodial + signing_keys: "the signing key 1 of the client1","the signing key 2 of the client1" + callback_url: https://callback.custodial-client1.com/api/v1/anchor/callback + allow_any_destination: false + destination_accounts: destAccount1,destAccount2 + - name: custodial-client2 + type: custodial + signing_keys: "the signing key of the client2", + + # noncustodial client + - name: noncustodial-client1 + type: noncustodial + domains: noncustodial-client1.co,noncustodial-client1.com + callback_url: https://callback.noncustodial-client1.co/api/v2/anchor/callback + - name: noncustodial-client2 + type: noncustodial + domains: noncustodial-client2.com +``` + +```bash +# dev.env +# custodial client +CLIENTS[0]_NAME=custodial-client1 +CLIENTS[0]_TYPE=custodial +CLIENTS[0]_SIGNING_KEYS="the signing key 1 of the client1","the signing key 2 of the client1" +CLIENTS[0]_CALLBACK_URL=https://callback.custodial-client1.com/api/v1/anchor/callback +CLIENTS[0]_ALLOW_ANY_DESTINATION=false +CLIENTS[0]_DESTINATION_ACCOUNTS=destAccount1,destAccount2 +CLIENTS[1]_NAME=custodial-client2 +CLIENTS[1]_TYPE=custodial +CLIENTS[1]_SIGNING_KEYS="the signing key of the client2" + +# noncustodial client +CLIENTS[2]_NAME=noncustodial-client1 +CLIENTS[2]_TYPE=noncustodial +CLIENTS[2]_DOMAINS=noncustodial-client1.co,noncustodial-client1.com +CLIENTS[2]_CALLBACK_URL=https://callback.noncustodial-client1.co/api/v2/anchor/callback +CLIENTS[3]_NAME=noncustodial-client2 +CLIENTS[3]_TYPE=noncustodial +CLIENTS[3]_DOMAINS=noncustodial-client2.com +``` + + + +`SEP10_CLIENT_ATTRIBUTION_REQUIRED` informs the Anchor Platform whether it should allow users of noncustodial wallets to authenticate without the wallet also identifying itself. + +`CLIENTS` is the list of outside wallet servers or clients for the Anchor server to safely communicate with. + +## Modify a Stellar Info File + +Next, let's modify `stellar.toml` file created [earlier][sep1-ap]. Wallets need to know that SEP-10 functionality is supported by your business. + + + +```toml +# dev.stellar.toml +ACCOUNTS = ["add your public keys for your distribution accounts here"] +SIGNING_KEY = "add your signing key here" +NETWORK_PASSPHRASE = "Test SDF Network ; September 2015" + +WEB_AUTH_ENDPOINT = "http://localhost:8080/auth" + +[DOCUMENTATION] +ORG_NAME = "Your organization" +ORG_URL = "Your website" +ORG_DESCRIPTION = "A description of your organization" +``` + + + +[sep1-ap]: ../sep1/README.mdx diff --git a/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/sep24/README.mdx b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/sep24/README.mdx new file mode 100644 index 000000000..28a0f666a --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/sep24/README.mdx @@ -0,0 +1,11 @@ +--- +title: Hosted Deposits and Withdrawals +sidebar_position: 60 +--- + +import DocCardList from "@theme/DocCardList"; + +SEP-24 allows for a means by which wallets and/or exchanges allow the user to +directly interact with an on & off-ramp. + + diff --git a/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/sep24/configuration.mdx b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/sep24/configuration.mdx new file mode 100644 index 000000000..1b0df6306 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/sep24/configuration.mdx @@ -0,0 +1,190 @@ +--- +title: Configuration +sidebar_position: 20 +--- + +import { CodeExample } from "@site/src/components/CodeExample"; + +## Modify a Stellar Info File + +Next, let's modify `stellar.toml` file created [earlier][sep1-ap]. Wallets need to know that SEP-24 functionality is supported by your business, and they also need to know all currencies you support. + + + +```toml +# dev.stellar.toml +ACCOUNTS = ["add your public keys for your distribution accounts here"] +SIGNING_KEY = "add your signing key here" +NETWORK_PASSPHRASE = "Test SDF Network ; September 2015" + +TRANSFER_SERVER_SEP0024 = "http://localhost:8080/sep24" +WEB_AUTH_ENDPOINT = "http://localhost:8080/auth" + +# Add support for USDC +[[CURRENCIES]] +code = "USDC" +issuer = "GBBD47IF6LWK7P7MDEVSCWR7DPUWV3NY3DTQEVFL4NAT4AQH3ZLLFLA5" +status = "test" +is_asset_anchored = false +desc = "USD Coin issued by Circle" + +# Optionally, add support for XLM +[[CURRENCIES]] +code = "native" +status = "test" +is_asset_anchored = false +anchor_asset_type = "crypto" +desc = "XLM, the native token of the Stellar network." + +[DOCUMENTATION] +ORG_NAME = "Your organization" +ORG_URL = "Your website" +ORG_DESCRIPTION = "A description of your organization" +``` + + + +Note that you'll need to create another file for your production deployment that uses the public network's passphrase, your production service URLs, your Mainnet distribution accounts and signing key, as well as the Mainnet issuing accounts of the assets your service utilizes. + +## Enable Hosted Deposits & Withdrawals + +Now you're ready to enable hosted deposits and withdrawals via the SEP-24 API. Specify the following in your `dev.assets.yaml` file, and change the values depending on your preferences. This example asset file will enable support for Circle's USDC and a fiat USD. + + + +```yaml +# dev.assets.yaml +assets: + - schema: stellar + code: USDC + issuer: GBBD47IF6LWK7P7MDEVSCWR7DPUWV3NY3DTQEVFL4NAT4AQH3ZLLFLA5 + distribution_account: GBLSAHONJRODSFTLOV225NZR4LHICH63RIFQTQN37L5CRTR2IMQ5UEK7 + significant_decimals: 2 + sep24_enabled: true + deposit: + enabled: true + withdraw: + enabled: true + - schema: iso4217 + code: USD + significant_decimals: 2 + deposit: + enabled: true + withdraw: + enabled: true + # Optional support for XLM + - schema: stellar + code: native + distribution_account: GBLSAHONJRODSFTLOV225NZR4LHICH63RIFQTQN37L5CRTR2IMQ5UEK7 + significant_decimals: 7 + sep24_enabled: true + deposit: + enabled: true + withdraw: + enabled: true +``` + + + +The information provided for the `assets` value closely maps to the information that will be exposed to the wallet application using the [`GET /info`][sep24-get-info] SEP-24 endpoint. The Anchor Platform also uses this information to validate requests made to your service. + +Add the following variables to your environment file. + + + +```bash +# dev.env +SEP24_ENABLED=true +SEP24_INTERACTIVE_URL_BASE_URL=http://example.com +SEP24_MORE_INFO_URL_BASE_URL=http://example.com +SECRET_SEP24_INTERACTIVE_URL_JWT_SECRET="your encryption key shared with your business server" +SECRET_SEP24_MORE_INFO_URL_JWT_SECRET="your encryption key shared with your business server" +``` + + + +`SEP24_INTERACTIVE_URL_BASE_URL` is the URL that the Anchor Platform will provide to wallet applications when they initiate transactions. Wallet applications will open this URL in a web view inside their app, handing over control of the user experience from the wallet to your business. This URL points to the web widget your business implements. It contains all business-defined logic. We'll dive further into this experience in subsequent sections. + +`SEP24_MORE_INFO_URL_BASE_URL` is the URL that the Anchor Platform will provide to wallet applications when they want to show information about a transaction initiated previously. This URL is most often used by wallets in their transaction history views, and your business can define what information to display about the transaction. + +`SECRET_SEP24_INTERACTIVE_URL_JWT_SECRET` and `SECRET_SEP24_MORE_INFO_URL_JWT_SECRET` are encryption keys that the Anchor Platform will use to generate short-lived tokens it will add to the URLs provided to the wallet. Your business server must also have these keys in its environment so it can verify the token's signature. + +## Test With the Demo Wallet + +Wallets should now be able to discover, authenticate, and initiate transactions with your service! Your project and source files should now look something like this. + + + +``` +β”œβ”€β”€ dev.env +β”œβ”€β”€ docker-compose.yaml +β”œβ”€β”€ config +β”‚ β”œβ”€β”€ dev.assets.yaml +β”‚ β”œβ”€β”€ dev.stellar.toml +``` + + + +Your environment should now look like the following. + + + +```bash +# dev.env +ASSETS_TYPE=file +ASSETS_VALUE=/home/dev.assets.yaml + +SEP1_ENABLED=true +SEP1_TOML_TYPE=file +SEP1_TOML_VALUE=/home/dev.stellar.toml + +SEP10_ENABLED=true +SEP10_HOME_DOMAIN=localhost:8080 +SECRET_SEP10_SIGNING_SEED="a Stellar private key" +SECRET_SEP10_JWT_SECRET="a secret encryption key" + +SEP24_ENABLED=true +SEP24_INTERACTIVE_URL_BASE_URL=http://localhost:8081 +SECRET_SEP24_INTERACTIVE_URL_JWT_SECRET="your encryption key shared with your business server" +SECRET_SEP24_MORE_INFO_URL_JWT_SECRET="your encryption key shared with your business server" +``` + + + +To test this out, go to the [Stellar Demo Wallet][stellar-demo-wallet]. + +[![demo wallet connected to the anchor platform](/assets/anchor-platform-sep24-demo-wallet.png)](/assets/anchor-platform-sep24-demo-wallet.png) + +Initiate a transaction by doing the following: + +- Create a new keypair +- Click the "Add Asset" button and enter + - the code of the Stellar asset on your `stellar.toml` file + - your home domain, `localhost:8080` +- Select the dropdown and click "SEP-24 Deposit", then click "Start" + +The demo wallet should be able to find your `stellar.toml` file, authenticate using the Stellar keypair you just created, and initiate a transaction. However, when the demo wallet attempts to open the URL provided by the Anchor Platform, you'll get a not found page. + +[![demo wallet after initiating a transaction](/assets/anchor-platform-sep24-demo-wallet-widget.png)](/assets/anchor-platform-sep24-demo-wallet-widget.png) + +[sep-1]: https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0001.md +[sep-9]: https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0009.md +[sep-24]: https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0024.md +[sep-38]: https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0038.md +[sep24-get-info]: https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0024.md#info +[anchor-platform-image]: https://hub.docker.com/r/stellar/anchor-platform +[docker-compose]: https://docs.docker.com/compose/ +[minikube]: https://minikube.sigs.k8s.io/docs/ +[kubernetes]: https://kubernetes.io/ +[nginx]: https://www.nginx.com/ +[ap-default-values]: https://github.com/stellar/java-stellar-anchor-sdk/blob/develop/platform/src/main/resources/config/anchor-config-default-values.yaml +[stellar-demo-wallet]: https://demo-wallet.stellar.org +[stellar-lab]: https://laboratory.stellar.org/ +[postgresql]: https://www.postgresql.org/ +[aurora-postgresql]: https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.AuroraPostgreSQL.html +[h2]: https://www.h2database.com/html/main.html +[sqlite]: https://www.sqlite.org/index.html +[flyway]: https://documentation.red-gate.com/fd/welcome-to-flyway-184127914.html +[sep-24-ref-ui]: https://github.com/stellar/sep24-reference-ui +[sep-24-ref]: https://github.com/stellar/java-stellar-anchor-sdk/tree/develop/kotlin-reference-server +[sep1-ap]: ../sep1/README.mdx diff --git a/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/sep24/example.mdx b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/sep24/example.mdx new file mode 100644 index 000000000..5ed760ba7 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/sep24/example.mdx @@ -0,0 +1,438 @@ +--- +title: Example +sidebar_position: 40 +--- + +Integrating with the Anchor Platform involves three key areas: + +- Building a web-based user experience that can be opened in a mobile web view +- Providing transaction status updates to the Anchor Platform +- Fetching transaction status updates from the Anchor Platform + +## Building a Web-Based User Experience + +The Anchor Platform does not offer a white-label UI that your business can utilize, and instead expects the business to build their own UI and backend system. We won't build an entire on & off-ramp user experience in this guide, but will cover the ways in which your existing product should be updated to be compatible with the Anchor Platform. + +### Authentication + +If your business has an existing on & off-ramp product, you likely have an existing system for user authentication. However, because the Anchor Platform authenticates the user prior to providing the business's URL, requiring the user to go through another form of authentication is actually unnecessary. In this way, the Anchor Platform can be thought of as providing an alternative form of authentication. + +The business is free to continue requiring users to authenticate using their existing system, but the ideal user experience would skip this step and create an authenticated session for the user if they have already authenticated using their Stellar account. + +The Anchor Platform adds a JWT `token` query parameter to the business's URL given to the wallet application. This token is signed by the previously-configured `SECRET_SEP24_INTERACTIVE_URL_JWT_SECRET` value, and includes the information you need to identify the user. The process should look something like this: + +1. Pass the `token` added to the URL of your backend system +2. Verify the signature on the `token` and check its expiration +3. Create an authenticated session for the user identified by `token.sub` + +The decoded contents of the `token` will look something like this: + + + +```json +{ + "jti": "e26cf292-814f-4918-9b40-b4f76a300f98", + "sub": "GB244654NC6YPEFU3AY7L25COGES445P3Q63W6Q76JHR3UBJMLT2XBOB:1234567", + "exp": 1516239022, + "data": { + "first_name": "John", + "last_name": "Doe", + "email": "johndoe@example.com" + } +} +``` + + + +Note that the `sub` value identifies the user using a Stellar account and integer. This is what the value will be when custodial applications that use an omnibus account authenticate with your service. When non-custodial wallets authenticate, the token may look slightly different. + + + +```json +{ + "jti": "e26cf292-814f-4918-9b40-b4f76a300f98", + "sub": "GB244654NC6YPEFU3AY7L25COGES445P3Q63W6Q76JHR3UBJMLT2XBOB", + "exp": 1516239022, + "data": { + "client_domain": "api.vibrantapp.com", + "first_name": "John", + "last_name": "Doe", + "email": "johndoe@example.com" + } +} +``` + + + +The `sub` value here only contains a public key to identify the user, and the `data.client_domain` field identifies the wallet application used to authenticate. + +In both cases, all information in the `data` object is optional, and will only be present if the wallet provides that information. + +Let's add a backend server to our compose file that will be used to verify the token and create authenticated web sessions for users initiating transactions. + + + +```yaml +# docker-compose.yaml +--- +business-server: + build: . + ports: + - "8081:8081" + env_file: + - ./dev.env + depends_on: + - platform-server +``` + + + +Let's create a simple Docker container for our application. + + + +```docker +FROM node:19 + +WORKDIR /home +COPY . . +RUN npm install + +CMD ["node", "server.js"] +``` + + + +Now let's create a minimal NodeJS application. + + + +```bash +yarn init -y +yarn add express jsonwebtoken +touch server.js +``` + + + +Below is an example of a backend server authenticating a user using NodeJS. + + + +```js +# server.js +const express = require("express"); +const jwt = require("jsonwebtoken"); +const app = express(); +const port = process.env.BUSINESS_SERVER_PORT; + +app.use(express.json()); + +/* + * We'll store user session data in memory, but production systems + * should store this data somewhere more persistent. + */ +const sessions = {}; + +/* + * Create an authenticated session for the user. + * + * Return a session token to be used in future requests as well as the + * user data. Note that you may not have a user for the stellar account + * provided, in which case the user should go through your onboarding + * process. + */ +app.post("/session", async (req, res) => { + let decodedPlatformToken; + try { + decodedPlatformToken = validatePlatformToken(req.body.platformToken); + } catch (err) { + res.status = 400; + res.send({ "error": err }); + return; + } + let user = getUser(decodedPlatformToken.sub); + let sessionToken = jwt.sign( + { "jti": decodedPlatformToken.jti }, + process.env.SESSION_JWT_SECRET + ); + sessions[sessionToken] = user; + res.send({ + "token": sessionToken, + "user": user + }); +}); + +/* + * Validate the signature and contents of the platform's token + */ +function validatePlatformToken(token) { + if (!token) { + throw "missing 'platformToken'"; + } + let decodedToken; + try { + decodedToken = jwt.verify(token, process.env.SECRET_SEP10_JWT_SECRET); + } catch { + throw "invalid 'platformToken'"; + } + if (!decodedToken.jti) { + throw "invalid 'platformToken': missing 'jti'"; + } + return decodedToken; +} + +/* + * Query your own database for the user based on account:memo string parameter + */ +function getUser(sub) { + return null; +} + +app.listen(port, () => { + console.log(`business server listening on port ${port}`); +}); +``` + + + +Run this with the platform server and database and initiate a new transaction with the [demo wallet][stellar-demo-wallet]. Then, we'll send the token to our server. + + + +```bash +curl \ + -X POST \ + -H 'Content-Type: application/json' \ + -d '{"platformToken": ""}' \ + http://localhost:8081/session | jq +``` + + + +## Providing Updates to the Platform + +Let's create an endpoint for our business server that accepts the information collected in our UI. + + + +```js +# server.js + +// Production systems should either let the Anchor Platform generate its own memos +// or have your custodial service generate a memo for each transaction. +const transactionMemos = {}; + +app.post("/transaction", async (req, res) => { + let sessionToken; + try { + sessionToken = validateSessionToken(req.headers.get("authorization")); + } catch (err) { + res.status = 400; + res.send({ "error": err }) + return; + } + // assuming this is a withdrawal transaction, we'll provide a memo, which is + // required by our third-party custodian to credit us the payment. When the + // payment is made with this memo, we can match the on-chain payment with the + // transaction in the Anchor Platform's database. + transactionMemos[req.body.transaction.id] = parseInt(Math.random() * 100000); + let rpcRequestBody = [ + { + "id": 1, + "jsonrpc": "2.0", + "method": "request_onchain_funds", + "params": { + "transaction_id": req.body.transaction.id,, + "message": "waiting for the user to provide off-chain funds.", + "amount_in": { + "amount": req.body.amount_in.amount, + "asset": "stellar:USDC:GBBD47IF6LWK7P7MDEVSCWR7DPUWV3NY3DTQEVFL4NAT4AQH3ZLLFLA5" + }, + "amount_out": { + "amount": req.body.amount_out.amount, + "asset": "iso4217:USD" + }, + "amount_fee": { + "amount": req.body.amount_fee.amount, + "asset": "stellar:USDC:GBBD47IF6LWK7P7MDEVSCWR7DPUWV3NY3DTQEVFL4NAT4AQH3ZLLFLA5" + }, + "destination_account": "GD...G", + "memo": transactionMemos[req.body.transaction.id], + "memo_type": "id" + } + } + ]; + let platformResponse; + try { + platformResponse = await updatePlatformTransaction(rpcRequestBody); + } catch (err) { + res.status = 500; + res.send({ "error": err }) + return; + } + res.send({ + "transaction": platformResponse.records[0] + }); +}); + +function validateSessionToken(authorizationHeader) { + let parts = authorizationHeader.split(" "); + if (parts.length != 2 || parts[0] != "Bearer") { + throw "invalid authorization header format"; + } + let sessionToken = parts[1]; + try { + jwt.verify(sessionToken, process.env.SESSION_JWT_SECRET); + } catch { + throw "invalid session token"; + } + if (!sessions[sessionToken]) { + throw "expired session"; + } + return sessionToken; +} + +async function updatePlatformTransaction(requestBody) { + let response = await fetch( + `${process.env.PLATFORM_SERVER}`, + { + method: "POST", + headers: { + "Content-Type": "application/json" + }, + body: JSON.stringify(requestBody) + } + ); + if (response.status != 200) { + throw `unexpected status code: ${response.status}`; + } + return await response.json(); +} +``` + + + +This will update the Anchor Platform's database with the information provided and enable wallet applications to fetch this updated information so it can relay it back to the user. You should have already informed the user of the transaction's amounts and that your business's is waiting for the on-chain payment to arrive, but providing these updates allows users to view their transactions' statuses through their mobile application without opening the business' UI again. + +:::note + +At this time, the Anchor Platform does not send notifications to the wallet application when transaction statuses change, however, it is on our roadmap to add these notifications or "callback requests" so that wallet applications do not have to poll the Anchor Platform for updates. + +::: + +## Fetching Updates from the Platform + +If you only use the Anchor Platform to expose the SEP APIs to wallet applications, then you won't have a strong reason for fetching transaction status updates from the Anchor Platform, mostly because it won't update the transaction status until you make `JSON-RPC API` requests. + +However, if you use the Anchor Platform to monitor the Stellar network for incoming payments (associated with withdrawal transactions), the Anchor Platform will update transaction statuses when payments are received. + +There are two ways to fetch updates from the Anchor Platform, + +- Polling the Platform API's `GET /transactions/:id` endpoint for the transactions you're expecting a payment for +- Streaming transaction status change events from a Kafka cluster + +While streaming transaction status changes from a Kafka cluster may be a more robust and scalable approach, we're going to use the polling method in this guide. Setting up and using a Kafka cluster will be the subject of a different section of the docs. + +First, let's configure the Anchor Platform to observe the Stellar network for incoming payments. + + + +```yaml +# docker-compose.yml +--- +stellar-observer: + image: stellar/anchor-platform:latest + command: --stellar-observer + env_file: + - ./dev.env + volumes: + - ./config:/home + depends_on: + - db +``` + + + +The `--stellar-observer` command starts a process that monitors the distribution accounts configured in your `config.yaml` file for withdrawal payments. + +If a payment is sent to one of these accounts and the memo attached to the transaction matches a `memo` value provided or generated by the Anchor Platform, the Anchor Platform will consider the transaction that memo is associated with as received and update the transaction's status to `pending_anchor`. It does this by making a `JSON-RPC API` request, so we need to configure the URL it should use. + + + +```bash +# dev.env +PLATFORM_API_BASE_URL=http://platform-server:8085 +``` + + + +Let's make some additions to the `server.js` file so we can poll the Anchor Platform for our expected payments. + + + +```js +// server.js +... +/* + * Fetch the transaction data from the Platform API + * + * Production systems should have proper retry mechanisms. + */ +async function getPlatformTransaction(transactionId) { + let response = await fetch(`${process.env.PLATFORM_SERVER}/transactions/${transactionId}`) + if (response.status != 200) { + throw `unexpected status code: ${response.status}`; + } + return await response.json(); +} + +(async () => { + while (true) { + await new Promise(r => setTimeout(r, 2000)); + let requestPromises; + for (const transactionId in transactionMemos) { + requestPromises.push(getPlatformTransaction(transactionId)) + } + let transactions = await new Promise.all(requestPromises); + for (const transaction in transactions) { + // assuming all requests were successful + if (transaction.status == "pending_anchor") { + // initiate off-chain delivery of funds + console.log(`received payment for transaction ${transaction.id}`); + } + } + } +})() +``` + + + +## Full Example Implementation + +Stellar provides an example business server implementation for SEP-24. It's split into two parts: 1) a web UI, accessible for the end user; and 2) a back-end implementation, used to get and push updates from/to the Anchor Platform. + +The code for web UI can be found [here][sep-24-ref-ui] + +The code for the backend is a part of the Anchor Platform, and is available as a [submodule][sep-24-ref]. + +[sep-1]: https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0001.md +[sep-9]: https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0009.md +[sep-24]: https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0024.md +[sep-38]: https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0038.md +[sep24-get-info]: https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0024.md#info +[anchor-platform-image]: https://hub.docker.com/r/stellar/anchor-platform +[docker-compose]: https://docs.docker.com/compose/ +[minikube]: https://minikube.sigs.k8s.io/docs/ +[kubernetes]: https://kubernetes.io/ +[nginx]: https://www.nginx.com/ +[ap-default-values]: https://github.com/stellar/java-stellar-anchor-sdk/blob/develop/platform/src/main/resources/config/anchor-config-default-values.yaml +[stellar-demo-wallet]: https://demo-wallet.stellar.org +[stellar-lab]: https://laboratory.stellar.org/ +[postgresql]: https://www.postgresql.org/ +[aurora-postgresql]: https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.AuroraPostgreSQL.html +[h2]: https://www.h2database.com/html/main.html +[sqlite]: https://www.sqlite.org/index.html +[flyway]: https://documentation.red-gate.com/fd/welcome-to-flyway-184127914.html +[sep-24-ref-ui]: https://github.com/stellar/sep24-reference-ui +[sep-24-ref]: https://github.com/stellar/java-stellar-anchor-sdk/tree/develop/kotlin-reference-server diff --git a/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/sep24/faq.mdx b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/sep24/faq.mdx new file mode 100644 index 000000000..3631dcb83 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/sep24/faq.mdx @@ -0,0 +1,39 @@ +--- +title: FAQ +sidebar_position: 50 +--- + +### How To Use Interactive JWTs? + +As part of the flow, once a user makes an interactive withdrawal/deposit request, it will be processed by the Anchor Platform and forwarded to your service. The Anchor Platform will make a `GET` call to `?token=`. + +This JWT token will contain: + +1. `exp` is the expiration time of the token. You should check that the provided token has not expired. +2. `sub` is the account associated with this transaction. It can be used to identify the user account. Note that this value may be different from the account that will be used to receive/send funds. +3. `jti` is the hash of the transaction. +4. `data` is the extra payload that has been set by the user. It will always contain the Stellar `asset` wants to deposit or withdraw. If provided by the client, it will also contain the `amount` the user wants to transact, the `client_domain` of the wallet verified during SEP-10 authentication, and the `lang` (language) preference of the user, and `client_name` (defined as 'name' in [clients] configuration if provided). + +### How To Provide Fees? + +Currently, it's recommended to provide fees/exchange rates in the iFrame/web view of your application. + +[SEP-24] standard provides a `/fee` endpoint to allow businesses to set static fees for their transactions. However, it's not currently supported by the Anchor Platform. + +:::note + +/fee endpoint will be deprecated in the future. + +::: + +### How to identify the user account? + +You should use the `sub` field of the JWT token. For custodial wallets, this value will be in the format `account:memo`. Use the memo to identity the user. For noncustodial wallets, simply use the `sub` value itself, which will be equal to the user account. + +### How to identify the wallet? + +Utilize the `data.client_domain` attributes within the JWT token. In the presence of [clients] configuration, the JWT token will additionally incorporate the `data.client_name` field, enabling wallet identification. + +[sep-9]: https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0009.md +[sep-24]: https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0024.md +[clients]: ../sep10/README.mdx diff --git a/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/sep24/getting-started.mdx b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/sep24/getting-started.mdx new file mode 100644 index 000000000..9a27580f6 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/sep24/getting-started.mdx @@ -0,0 +1,33 @@ +--- +title: Getting Started +sidebar_position: 10 +--- + +This guide will walk you through configuring and integrating with the Anchor Platform for the purpose of building an on & off-ramp service compatible with [SEP-24][sep-24], the ecosystem's standardized protocol for hosted deposits and withdrawals. + +By leveraging the Anchor Platform's support for SEP-24, businesses make their on & off-ramp service available as an in-app experience through Stellar-based applications such as wallets and exchanges, extending their reach and connecting with users through the applications they already use. + +Before continuing with this section, make sure that you have already [installed][installation-ap] the Anchor Platform, and configured necessary features, required by SEP-24: [SEP-1 (Stellar Info File)][sep1-ap] and [SEP-10 (Stellar Authentication)][sep10-ap] + +## The Basic User Experience + +The complete customer experience a deposit and withdrawal goes something like this: + +1. The customer opens the SEP-24 wallet application of their choice +2. The customer selects an asset to deposit and the wallet finds an anchor (clients could also chose the specific anchor) +3. Once the wallet authenticates with the anchor, the customer begins entering their KYC and transaction information requested by the anchor +4. The wallet provides instructions, and the customer deposits real fiat currency with the anchor (e.g. makes a bank transfer) +5. Once the wallet receives the deposit, the customer receives the tokenized asset on the Stellar network from the anchor's distribution account + +The customer can then use the digital asset on the Stellar network for remittance, payments, trading, store of value, or another use case not listed here. At some later date, the customer could decide to withdraw their assets from the Stellar network, which would look something like this: + +1. The customer opens their wallet application +2. The customer selects the asset for withdrawal and wallet finds the anchor +3. After authenticating with the anchor, the wallet opens the given interactive URL and allows the customer to enter their transaction information (KYC has already been collected) +4. After asking for customer approval, the wallet sends the specified amount of the customer's asset balance to the anchor's distribution account on Stellar +5. Once the anchor receives the payment, the customer receives the withdrawn funds via bank transfer. + +[sep-24]: https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0024.md +[installation-ap]: ../../admin-guide/getting-started.mdx +[sep1-ap]: ../sep1/README.mdx +[sep10-ap]: ../sep10/README.mdx diff --git a/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/sep24/integration.mdx b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/sep24/integration.mdx new file mode 100644 index 000000000..c45d246df --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/sep24/integration.mdx @@ -0,0 +1,1010 @@ +--- +title: Integration +sidebar_position: 30 +--- + +import { CodeExample } from "@site/src/components/CodeExample"; +import { AttributeTable } from "@site/src/components/AttributeTable"; +import Security from "../component/security/security.mdx"; +import UsingApiKey from "../component/security/api_key.mdx"; +import UsingJwt from "../component/security/jwt.mdx"; +import Rpc from "../component/rpc/rpc.mdx"; +import RpcRequest from "../component/rpc/request.mdx"; +import RpcResponse from "../component/rpc/response.mdx"; +import RpcError from "../component/rpc/error.mdx"; +import Observer from "../component/observer/observer.mdx"; + +One of the main points of interaction with the Anchor Platform is notifying the Anchor Platform about events related to the transaction. + +In general, you'll want to provide updates for the following events: + +- Your business is processing the KYC information provided by the user +- Your business is ready to receive funds from the user +- Your business has received funds from the user +- Your business has sent funds to the user +- Your business has processed a refund for the user's transaction +- Your business experienced an unexpected error + +This is done by making JSON-RPC requests to the Platform API's endpoint. JSON-RPC requests allow you to update the status of the transaction. To move the transaction to a specific status, it's necessary to make a corresponding JSON-RPC request and pass data that is required by this RPC method. + +The Anchor Platform JSON-RPC API is designed to notify the platform about changes in the status of the transaction. Given that, the API will be called every time a user or the anchor takes any action that progresses the transaction status in the flow. + +You can find out more about transaction flow and statuses in the [SEP-24 protocol document][sep-24] + +## Securing Platform API + + + +### Using API Key + + + +### Using JWT + + + +## Making JSON-RPC Requests + + + +### JSON-RPC Request + + + +### JSON-RPC Response + + + +### Error Codes + + + +## Updating Deposit Transaction Via JSON-RPC + +SEP-24 deposit flow diagram defines sequence/rules of the transaction's status transition and a set of JSON-RPC methods that should be called to change that status. You can't define the status you want to set for a specific transaction in your requests. Each JSON-RPC method defines data structures that it expects in request. If request doesn't contain a required attributes, the Anchor Platform will return and error and won't change status of the transaction. + +[![sep24 deposit flow](/assets/sep24-deposit-flow-diagram.png)](/assets/sep24-deposit-flow-diagram.png) + +:::tip + +Statuses in green are mandatory and define the shortest way. + +Statuses in yellow are optional and can be skipped. + +Statuses in red mean the transaction is in an error status or it has expired. + +::: + +### Ready to Receive Funds + +The first step of the deposit flow after starting the deposit itself is collecting KYC. It's usually done in the web-app, but can also be optionally provided by the wallet application, using [SEP-9]. Once the necessary KYC is collected, a `request_offchain_funds` JSON-RPC request should be made. + + + +```json +// request-offchain-funds.json +[ + { + "id": 1, + "jsonrpc": "2.0", + "method": "request_offchain_funds", + "params": { + "transaction_id": "", + "message": "Request offchain funds", + "amount_in": { + "amount": 10, + "asset": "iso4217:USD" + }, + "amount_out": { + "amount": 9, + "asset": "stellar:USDC:GBBD47IF6LWK7P7MDEVSCWR7DPUWV3NY3DTQEVFL4NAT4AQH3ZLLFLA5" + }, + "amount_fee": { + "amount": 1, + "asset": "iso4217:USD" + }, + "amount_expected": { + "amount": 10 + } + } + } +] +``` + + + +- `amount_in` is the amount the user has to sent to the business. +- `amount_out` is the amount the user will receive. +- `amount_fee` is the total amount of fees collected by the business. +- `asset` is part of the `amount_x` field and is in a SEP-38 format. In this example, it's set to USD, assuming the user made a bank transfer to the system using USD. + +Information abouts amounts (in/out/fee) is required if you want to move the transaction from the `incomplete` to the `pending_user_transfer_start` status. If transaction status is changed from `pending_anchor` to `pending_user_transfer_start`, you can skip defining the amounts. + +To execute this, you need to run: + + + +```bash +./call-json-rpc.sh request-offchain-funds.json +``` + + + +:::tip + +When the KYC process is long (for example, ID verification), it's advised to first set the transaction status to `pending_anchor` by using `notify_interactive_flow_completed` JSON-RPC request. This will indicate to the user that KYC is being processed. + +::: + +### Processing KYC Information + +:::tip + +This step is optional. Most businesses don't use it. You can skip it and go to the [next step](#funds-received). + +Using this status is recommended when KYC verification may need to be performed asynchronously. + +::: + +You **must** specify the `amount_x` fields. + + + +```json +// kyc-in-process.json +[ + { + "id": 1, + "jsonrpc": "2.0", + "method": "notify_interactive_flow_completed", + "params": { + "transaction_id": "", + "message": "Interactive flow completed.", + "amount_in": { + "amount": 10, + "asset": "iso4217:USD" + }, + "amount_out": { + "amount": 9, + "asset": "stellar:USDC:GBBD47IF6LWK7P7MDEVSCWR7DPUWV3NY3DTQEVFL4NAT4AQH3ZLLFLA5" + }, + "amount_fee": { + "amount": 1, + "asset": "iso4217:USD" + }, + "amount_expected": { + "amount": 10 + } + } + } +] +``` + + + +To execute this, you need to run: + + + +```bash +./call-json-rpc.sh kyc-in-process.json +``` + + + +### Funds Received + +If offchain funds were received, you'll want to provide an updated transaction information. + + + +```json +// offchain-funds-received.json +[ + { + "id": 1, + "jsonrpc": "2.0", + "method": "notify_offchain_funds_received", + "params": { + "transaction_id": "", + "message": "Offchain funds received", + "funds_received_at": "2023-07-04T12:34:56Z", + "external_transaction_id": "7...9", + "amount_in": { + "amount": 10 + }, + "amount_out": { + "amount": 9 + }, + "amount_fee": { + "amount": 1 + }, + "amount_expected": { + "amount": 10 + } + } + } +] +``` + + + +- `funds_received_at` is the date and time of receiving funds +- `external_transaction_id` is the ID of transaction on external network + +The amount fields are optional. If skipped, the values from previous JSON-RPC requests will be taken. + +To execute this, you need to run: + + + +```bash +./call-json-rpc.sh offchain-funds-received.json +``` + + + +### Waiting For User Funds + +In a real world, the transfer confirmation process may take time. In such cases, transactions should be set to a new status indicating that the confirmation of the transfer has been received but the funds themselves have not been received yet. + + + +```json +// offchain-funds-sent.json +[ + { + "id": 1, + "jsonrpc": "2.0", + "method": "notify_offchain_funds_sent", + "params": { + "transaction_id": "", + "message": "Offchain funds sent", + "funds_received_at": "2023-07-04T12:34:56Z", + "external_transaction_id": "7...9" + } + } +] +``` + + + +To execute this, you need to run: + + + +```bash +./call-json-rpc.sh offchain-funds-sent.json +``` + + + +### Sending Onchain Funds + +Next, send a transaction on the Stellar network to fulfill a user request. After the transaction completion, it's necessary to send the `notify_onchain_funds_sent` JSON-RPC request to notify a user that the funds were successfully sent. + + + +```json +// onchain-funds-sent.json +[ + { + "id": 1, + "jsonrpc": "2.0", + "method": "notify_onchain_funds_sent", + "params": { + "transaction_id": "", + "message": "Onchain funds sent", + "stellar_transaction_id": "7...9" + } + } +] +``` + + + +- `stellar_transaction_id` is the transaction id on Stellar network of the transfer + +To execute this, you need to run: + + + +```bash +./call-json-rpc.sh onchain-funds-sent.json +``` + + + +After this JSON-RPC request, the transaction will be transferred to the `completed` status. + +### Sending Payment Via Custody Service + +The Anchor Platform provides a possibility to send a payment via custody services, such as Fireblocks. To make a payment via custody service, it's necessary to make the following JSON-RPC request: + + + +```json +// do-stellar-payment.json +[ + { + "id": 1, + "jsonrpc": "2.0", + "method": "do_stellar_payment", + "params": { + "transaction_id": "", + "message": "Custody payment started" + } + } +] +``` + + + +To execute this, you need to run: + + + +```bash +./call-json-rpc.sh do-stellar-payment.json +``` + + + +After successful processing of the payment on a custody service, the Anchor Platform will automatically make the `notify_onchain_funds_sent` JSON-RPC request and the status of the transaction will be changed to `completed`. + +:::caution + +A user account may not be ready to receive funds. You can check that the account has established a [trustline](/docs/learn/glossary#trustline). Otherwise, you can set the status of the transaction to the `pending_trust` to indicate that the anchor is waiting for the user to establish the trustline. + +If custody integration is enabled, the Anchor Platform will do this validation for you automatically. + +::: + +### Pending Trust + +This status has to be set if a payment requires an asset trustline that wasn't configured by the user. There are two ways of how the transaction may be moved to the `pending_trust` status. The first one is processing of a payment via custody service in case it detected that the trustline isn't configured. The second one is when the business itself detects that the trustline is missing and wants to notify the user that it has to be configured. To move the transaction to the `pending_trust` status, it's necessary to make the following JSON-RPC request: + + + +```json +// request-trust.json +[ + { + "id": 1, + "jsonrpc": "2.0", + "method": "request_trust", + "params": { + "transaction_id": "", + "message": "Asset trustine not configured" + } + } +] +``` + + + +To execute this, you need to run: + + + +```bash +./call-json-rpc.sh request-trust.json +``` + + + +:::info + +Payment via custody service periodically checks if the trustline was configured. If it was, it will automatically send a payment to a custody service and change the status of the transaction to `pending_stellar`. + +::: + +### Trust Set + +This status has to be set if the business has detected that the trustline was or wasn't configured by user. + + + +```json +// trust-set.json +[ + { + "id": 1, + "jsonrpc": "2.0", + "method": "notify_trust_set", + "params": { + "transaction_id": "", + "message": "Asset trustine set", + "success": "true" + } + } +] +``` + + + +- `success` flag which defines if trustline was or wasn't configured by user + +To execute this, you need to run: + + + +```bash +./call-json-rpc.sh trust-set.json +``` + + + +:::info + +Depending on the `success` flag, the status of the transaction will be changed to `pending_stellar` if the trustline was set, or to `pending_anchor` if it wasn't. + +::: + +### Sending Refund Via Custody Service + +There is a possibility to send funds back to the user (refund). You can refund the whole sum(full refund) or do a set of partial refunds. Also, if user sent more money than expected, you can refund a part of the sum back to the user and send the rest as onchain funds. + + + +```json +// refund-sent.json +[ + { + "id": 1, + "jsonrpc": "2.0", + "method": "notify_refund_sent", + "params": { + "transaction_id": "", + "message": "Refund sent", + "refund": { + "id": "1c186184-09ee-486c-82a6-aa7a0ab1119c", + "amount": { + "amount": 10, + "asset": "iso4217:USD" + }, + "amount_fee": { + "amount": 1, + "asset": "iso4217:USD" + } + } + } + } +] +``` + + + +To execute this, you need to run: + + + +```bash +./call-json-rpc.sh refund-sent.json +``` + + + +:::info + +If a sum of refunds is less than `amount_in`, the status of the transaction will be set to `pending_anchor`. Only if the sum of refunds is equal to `amount_in`, the status of the transaction will be set to `refunded`. + +::: + +### Refund Pending + +It's similar to [Refund sent](#refund-sent), but it handles a case when a refund has been submitted to external network but is not yet confirmed. The status of the transaction is set to `pending_external`. This is the status that will be set when waiting for Bitcoin or other external crypto network to complete a transaction, or when waiting for a bank transfer. + +### Transaction Error + +If you encounter an unrecoverable error when processing the transaction, it's required to set the transaction status to `error`. You can use the message field to describe the error details. + + + +```json +// transaction-error.json +[ + { + "id": 1, + "jsonrpc": "2.0", + "method": "notify_transaction_error", + "params": { + "transaction_id": "", + "message": "Error occurred" + } + } +] +``` + + + +To execute this, you need to run: + + + +```bash +./call-json-rpc.sh transaction-error.json +``` + + + +:::tip + +If a user has made a transfer, you should do a transaction recovery, and then you can retry processing the transaction or initiate a refund. + +::: + +### Expired Transaction + +Your business may want to expire transactions that have been abandoned by the user after some time. It's a good practice to clean up inactive transactions in the `incomplete` status. To do so, simply change the transaction status to `expired`. + + + +```json +// transaction-expired.json +[ + { + "id": 1, + "jsonrpc": "2.0", + "method": "notify_transaction_expired", + "params": { + "transaction_id": "", + "message": "Transaction expired" + } + } +] +``` + + + +To execute this, you need to run: + + + +```bash +./call-json-rpc.sh transaction-expired.json +``` + + + +:::tip + +This JSON-RPC method can't be used after the user has made a transfer. + +::: + +### On-Hold Transaction + +In rare cases, you may want to pause current transaction and request more information from the user (after the transfer has been received). +This could be used for compliance use cases. + + + +```json +// transaction-hold.json +[ + { + "id": 1, + "jsonrpc": "2.0", + "method": "notify_transaction_on_hold", + "params": { + "transaction_id": "", + "message": "Transaction is on hold. Please contact customer support to resolve the hold." + } + } +] +``` + + + +To execute this, you need to run: + + + +```bash +./call-json-rpc.sh transaction-hold.json +``` + + + +### Transaction Recovery + +Transaction status can be changed from `error/expired` to `pending_anchor`. After recovery, you can refund the received assets or proceed with processing of the transaction. To recover a transaction, it's necessary to make the following JSON-RPC request: + + + +```json +// transaction-recovery.json +[ + { + "id": 1, + "jsonrpc": "2.0", + "method": "notify_transaction_recovery", + "params": { + "transaction_id": "", + "message": "Transaction recovered" + } + } +] +``` + + + +To execute this, you need to run: + + + +```bash +./call-json-rpc.sh transaction-recovery.json +``` + + + +## Updating Withdrawal Transaction Via JSON-RPC + +This diagram defines a sequence/rules of transaction's status transition for SEP-24 withdrawal flow. + +[![sep24 withdrawal flow](/assets/sep24-withdrawal-flow-diagram.png)](/assets/sep24-withdrawal-flow-diagram.png) + +:::tip + +Statuses in green are mandatory and define the shortest way. + +Statuses in yellow are optional and can be skipped. + +Statuses in red mean the transaction is in an error status or it has expired. + +::: + +Once the deposit flow is finished, implementing the withdrawal is straightforward. Some parts of the flow are similar and can be reused. + +The starting point both for withdrawal and for deposit is the same. + +### Ready to Receive Funds + +Similar to deposit, the next step is to notify the user that the anchor is ready to receive funds. However, as your service will be receiving transactions over the Stellar network, the update will look differently. + + + +```json +// request-onchain-funds.json +[ + { + "id": 1, + "jsonrpc": "2.0", + "method": "request_onchain_funds", + "params": { + "transaction_id": "", + "message": "Request onchain funds", + "amount_in": { + "amount": 10, + "asset": "stellar:USDC:GBBD47IF6LWK7P7MDEVSCWR7DPUWV3NY3DTQEVFL4NAT4AQH3ZLLFLA5" + }, + "amount_out": { + "amount": 9, + "asset": "iso4217:USD" + }, + "amount_fee": { + "amount": 1, + "asset": "stellar:USDC:GBBD47IF6LWK7P7MDEVSCWR7DPUWV3NY3DTQEVFL4NAT4AQH3ZLLFLA5" + }, + "amount_expected": { + "amount": 10 + }, + "destination_account": "GD...G", + "memo": "12345", + "memo_type": "id" + } + } +] +``` + + + +- `memo` Value of memo to attach to the transaction +- `memo_type` Type of memo that the anchor should attach to the transaction +- `destination_account` Destination account + +To execute this, you need to run: + + + +```bash +./call-json-rpc.sh request-onchain-funds.json +``` + + + +:::tip + +Setting `memo`, `memo_type`, and `destination_account` is optional. + +If integration with a third-party custodian is enabled, the Anchor Platform can generate `memo`, `memo_type`, and `destination_address` if a corresponding `deposit_info_generator_type` is chosen. Also, you can provide `memo` and `memo_type` to the request as shown above. Note that the memo must be unique, this is what helps to associate Stellar transactions with SEP transactions. + +If your business manages the assets, the Anchor Platform can generate memos for you. When the status is changed to `pending_user_transfer_start`, the Anchor Platform sets the `memo` and `memo_type` automatically (only if it's not included in the request). + +::: + +:::note + +The Stellar account that will be used to receive funds should be configured. + +::: + +### Processing KYC Information + +This step is optional, and it's similar to [Processing KYC Information](#processing-kyc-information) of the deposit flow. + +### Funds Received + +If onchain funds were received, you need to provide amounts and change the status of the transaction to `pending_anchor`. + + + +```json +// onchain-funds-received.json +[ + { + "id": 1, + "jsonrpc": "2.0", + "method": "notify_onchain_funds_received", + "params": { + "transaction_id": "", + "message": "Onchain funds received", + "stellar_transaction_id": "7...9", + "amount_in": { + "amount": 10 + }, + "amount_out": { + "amount": 9 + }, + "amount_fee": { + "amount": 1 + } + } + } +] +``` + + + +To execute this, you need to run: + + + +```bash +./call-json-rpc.sh onchain-funds-received.json +``` + + + +:::tip + +This method will be called automatically by the custody server if the custody integration is enabled. + +::: + +### Amount Updated + +If onchain funds were received, but for some reason the `amount_in` differs from specified in the interactive flow (`amount_expected`), you can update `amount_out` and `amount_fee` to make them correspond to the actual `amount_in`. The status of the transaction in this case won't be changed and will be equal to `pending_anchor`. + + + +```json +// amounts-updated.json +[ + { + "id": 1, + "jsonrpc": "2.0", + "method": "notify_amounts_updated", + "params": { + "transaction_id": "", + "message": "Amounts updated", + "amount_out": { + "amount": 9 + }, + "amount_fee": { + "amount": 1 + } + } + } +] +``` + + + +To execute this, you need to run: + + + +```bash +./call-json-rpc.sh amounts-updated.json +``` + + + +:::note + +Only `amount_out` and `amount_fee` can be updated using this JSON-RPC request, and you don't need to specify the assets of the amounts. + +::: + +### Offchain Funds Sent + +To complete the transaction and change its status to `completed`, you need to make the `notify_offchain_funds_sent` JSON-RPC request. + + + +```json +// offchain-funds-sent.json +[ + { + "id": 1, + "jsonrpc": "2.0", + "method": "notify_offchain_funds_sent", + "params": { + "transaction_id": "", + "message": "Offchain funds sent", + "funds_sent_at": "2023-07-04T12:34:56Z", + "external_transaction_id": "a...c" + } + } +] +``` + + + +To execute this, you need to run: + + + +```bash +./call-json-rpc.sh offchain-funds-sent.json +``` + + + +### Offchain Funds Available + +You can move transaction status to `pending_user_transfer_complete` if offchain funds were sent, and if it's ready for the user / recipient to pick it up. + + + +```json +// offchain-funds-available.json +[ + { + "id": 1, + "jsonrpc": "2.0", + "method": "notify_offchain_funds_available", + "params": { + "transaction_id": "", + "message": "Offchain funds available", + "external_transaction_id": "a...c" + } + } +] +``` + + + +To execute this, you need to run: + + + +```bash +./call-json-rpc.sh offchain-funds-available.json +``` + + + +### Offchain Funds Pending + +Another option is to move the transaction's status to `pending_external`. This status means that the payment has been submitted to an external network, but is not yet confirmed. + + + +```json +// offchain-funds-pending.json +[ + { + "id": 1, + "jsonrpc": "2.0", + "method": "notify_offchain_funds_pending", + "params": { + "transaction_id": "", + "message": "Offchain funds pending", + "external_transaction_id": "a...c" + } + } +] +``` + + + +To execute this, you need to run: + + + +```bash +./call-json-rpc.sh offchain-funds-pending.json +``` + + + +### Refund Sent + +The refund logic works in the same way as for the deposit flow. For more details, see [Refund Sent](#refund-sent) of the deposit flow. + +### Sending Refund Via Custody Service + +Integration with a custody service allows you to do a refund via a custody service, such as Fireblocks. + + + +```json +// do-stellar-refund.json +[ + { + "id": 1, + "jsonrpc": "2.0", + "method": "do_stellar_refund", + "params": { + "transaction_id": "", + "message": "Do stellar refund", + "refund": { + "amount": { + "amount": 9, + "asset": "stellar:USDC:GBBD47IF6LWK7P7MDEVSCWR7DPUWV3NY3DTQEVFL4NAT4AQH3ZLLFLA5" + }, + "amount_fee": { + "amount": 1, + "asset": "stellar:USDC:GBBD47IF6LWK7P7MDEVSCWR7DPUWV3NY3DTQEVFL4NAT4AQH3ZLLFLA5" + } + } + } + } +] +``` + + + +To execute this, you need to run: + + + +```bash +./call-json-rpc.sh do-stellar-refund.json +``` + + + +:::note + +Similarly to the deposit flow, you can make a full refund or a set of partial refunds. The transaction will stay in `pending_anchor` status until the sum of refunds is less than `amount_in`. If the sum of refunds is equal to `amount_in`, the Anchor Platform will automatically change the status of the transaction to `refunded`. + +::: + +### Transaction Error + +Works in the same manner as for the deposit flow. For more details, see [Transaction Error](#transaction-error) of the deposit flow. + +### Expired Transaction + +Works in the same manner as for the deposit flow. For more details, see [Expired Transaction](#expired-transaction) of the deposit flow. + +### On-Hold Transaction + +Works in the same manner as for the deposit flow. For more details, see [On-Hold Transaction](#on-hold-transaction) of the deposit flow. + +### Transaction Recovery + +Works in the same manner as for the deposit flow. For more details, see [Transaction Recovery](#transaction-recovery) of the deposit flow. + +## Tracking Stellar Transactions + + + +[sep-9]: https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0009.md +[sep-24]: https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0024.md +[json-rpc-methods]: ../../api-reference/rpc/methods/README.mdx diff --git a/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/sep24/setting-up-production-server.mdx b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/sep24/setting-up-production-server.mdx new file mode 100644 index 000000000..c563455fa --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/sep24/setting-up-production-server.mdx @@ -0,0 +1,112 @@ +--- +title: Set Up a Production Server +sidebar_position: 60 +--- + +import { CodeExample } from "@site/src/components/CodeExample"; + +Once the test server is live and you have tested both deposit and withdraw flows, it's time to get started with the real deploy connected to real KYC and real banking rails providers. Before using any banking APIs, it's critical that you perform a full security audit on the system to make sure that there aren't any vulnerabilities. + +## Deploying a Secure Environment + +Make sure to keep the test server up, and deploy the production (mainnet) system in a separate environment. Having two deploys allows you to validate new features on the testnet before moving them to the final production deploy. You can also have a third staging environment if there's a big team working on this codebase and/or there will be many pushes to be tested internally before sharing with other institutions. + +To switch to Stellar's public (mainnet) network, all you have to do is change the network [passphrase](../../../../docs/learn/encyclopedia/network-configuration/network-passphrases) (for authenticating requests) and [Horizon URL](https://horizon.stellar.org/). + +You can copy your existing development configs to create a production configuration. + +First, you need to change your info file (`stellar.toml`): + + + +```toml +# stellar.toml +NETWORK_PASSPHRASE = "Public Global Stellar Network ; September 2015" +``` + + + +Next, change your Anchor Platform configuration in `production.env` file: + + + +```bash +# production.env +STELLAR_NETWORK_NETWORK="Public" +STELLAR_NETWORK_HORIZON_URL=https://horizon.stellar.org +``` + + + +## Connecting to Real KYC + +Most anchors need to collect [Know Your Customer](https://en.wikipedia.org/wiki/Know_your_customer) information to comply with local regulations before honoring deposits and withdrawals. The KYC flow usually consists of a simple form that gathers relevant information about the user such as name, email, address, age, and government-issued ID number. + +How you handle KYC is up to you: there are many services that provide KYC solutions through APIs and iFrames, and validate the input data and sync with governmental databases to verify requirements. Each jurisdiction has specific KYC requirements, and they differ from jurisdiction to jurisdiction, so it's best to find a country-specific KYC provider that meets your needs. + +Some countries require different KYC fields depending on the amount to be deposited or withdrawn. If that's the case in your jurisdiction and you need to adapt your KYC forms based on the deposit or withdrawal amount, simply add an amount field before the KYC form, and make sure that the KYC fields are updated based on that value. + +KYC information should be linked to the session created through [Stellar Web Authentication](../sep10/README.mdx) and, consequently, to the user, so you only need to ask the user for it once. After the first KYC flow is complete, a user shouldn't have to input the information again. + +Make sure the errors and validation messages are clear and include instructions for what to do next to ensure a good user experience and increase the KYC conversion rate. You should also localize messages based on the user's language and location. + +## Pre-Filling the KYC Form + +Pre-filling the KYC form is a great way to reduce the friction of getting started using an anchor, and wallets usually provide a set of fields that are commonly used throughout the ecosystem. In summary, the anchor can render the KYC form with the user's values that were previously sent by the wallet in the `/transactions/deposit/interactive` and `/transactions/withdraw/interactive` endpoints. + +All fields from [SEP-9](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0009.md) can be sent by wallets in the previously mentioned endpoints, but the most common are: email, first name, last name and phone number. Also, you should still enable the pre-filled fields to be editable, since the user might have inputted a different name in the Wallet's sign-up process, and could want to edit it before finalizing the Anchor's KYC process. + +All SEP-9 data that was sent from the wallet is a part of the [Interactive JWT](./faq.mdx#how-to-use-interactive-jwts), send by the Anchor Platform + +## Connecting to Real Banking Rails + +Fiat-backed token issuers are expected to manage a full reserve. That means there's a 1:1 relationship between Stellar-network tokens and money in the bank. Since each fiat token on Stellar is backed by, and can be redeemed for, an underlying, real-world asset, issuers of fiat-backed tokens need to connect to real banking rails to validate user deposits (through bank transfers, credit card payments, etc.) and to complete user withdrawals (generally through bank transfers). If you're an anchor honoring deposits and withdrawals of a token another organization issues, you'll follow a similar process. + +In order to fetch (and identify) a user transfer, issuers usually take one of two approaches: + +- API Polling: this option consists of fetching the bank's API, through a cron job, to check for the updated status of the list of transfers received by (and sent from) the issuer's bank account. Once the system confirms a new transaction and identifies that it relates to a specific deposit, it can send the digital funds to that user's account +- Webhook: not all banking rails support this option, but it's the leanest in terms of back-end logic. In this approach, the bank proactively hits an issuer's endpoint once it receives a new transfer, updating that information on the issuer's database. The issuer can then can match that transaction to an existing in-process deposit, and validate that the user can receive their digital funds + +There are many ways to identify that a specific bank transfer relates to a specific deposit (and, consequently, to a user). Some banks (and countries) have transfer infrastructure that allows the creation of a single bank account per transfer; others require users to add an identification parameter to their transfers. Some banks provide the user ID number in the transaction information so issuers can match that with the information provided in the KYC form. + +Make sure to do a full security audit on your systems when banking rails connections are in place. Some banks provide a testing API that can be used for development and deployment to testnet or staging environments, which means you can test and audit the codebase before moving to a final production-ready bank integration. For better security, some anchors also prefer to add a manual final step before approving withdrawal transfers. In terms of UX, this manual approval is acceptable as long as the wait times align with user expectations, which usually means they aren't longer than a couple of hours. + +## Testing Edge Cases + +Once your application is fully functional, it's a good idea to test different scenarios and edge cases to make sure the system is behaving as expected. Here's a list of testing suggestions that should cover a large amount of the application's edge cases: + +### General Tests + +- Test the interactive flow usability +- Test the interface using different locale information, and check for translated content including error messages, responses, date formatting, and number formatting + +### KYC Tests + +- Check that KYC appears with a new wallet SK +- Check that KYC doesn't accept incorrectly formatted inputs, and that the error messages are comprehensible +- Check that you can use the same KYC information (email, phone number, username, etc) multiple times +- Check that you can go through KYC multiple times with the same Stellar SK. + +### Interactive Test + +- Check that the deposit flow goes through, and that the banking rails are working +- Check that you cannot make a withdrawal with a value higher than the current balance +- Check that the withdrawal flow goes through, and that the banking rails are working + +### Security Tests + +- Make sure platform endpoints are secured + +## Polishing and Internationalization + +Supporting two languages (English and the fiat currency country language) allows users to have a seamless experience while navigating through screens, and supports international institutions (like wallets) that need to test the product before starting new integrations. + +You can support multiple languages in your webapp by using the `Accept-Language` parameter from the http request headers to localize the content and allowing users to change that in a simple way (e.g. a flag icon on the top bar). If a specific wallet doesn't send the header parameter, we recommend showing the user a language selection screen in the beginning of the deposit and withdraw processes. Once a user chooses a language, you can store their selection so you only need to ask them once. In addition to localizing text, make sure to check number formatting, dates, etc. + +Having a group of beta testers is a great way to check if there are any edge cases that need polishing, and to confirm that the system is working well with a variety of user inputs. You can beta test using a soft launch stage before you start putting effort into marketing and distribution. Documenting the testing process with screenshots and videos is very helpful for future security audits, and gives new partners and potential users clarity and confidence in the product. + +## Connecting to Wallets + +All Anchor user interactions are done through a Wallet, so it's vital for Anchors to be connected to Wallets that have a good market penetration in the region where the business is most focused. Connecting to Wallets is a simple process, since both ends of that integration are already compliant with SEPs. + +Stellar.org maintains a [list of wallets](https://www.stellar.org/ecosystem/projects), many of which currently support SEP-24 Sending them a message with more information on an asset and an issuer account is a great way to start getting some real users to the Anchor. diff --git a/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/sep31/README.mdx b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/sep31/README.mdx new file mode 100644 index 000000000..22f975e8b --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/sep31/README.mdx @@ -0,0 +1,11 @@ +--- +title: Cross-Border Payments +sidebar_position: 70 +--- + +import DocCardList from "@theme/DocCardList"; + +SEP-31 allows for a means by which wallets and/or exchanges interact with +Stellar's existing set of send-side services. + + diff --git a/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/sep31/configuration.mdx b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/sep31/configuration.mdx new file mode 100644 index 000000000..c2f86ec95 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/sep31/configuration.mdx @@ -0,0 +1,382 @@ +--- +title: Configuration +sidebar_position: 20 +--- + +import { CodeExample } from "@site/src/components/CodeExample"; + +## Modify a Stellar Info File + +Let's start by modifying our `stellar.toml` file created [earlier][sep1-ap]. Wallets need to know that SEP-31 functionality is supported by your business, and they also need to know all currencies you support. + + + +```toml +# dev.stellar.toml +ACCOUNTS = ["add your public keys for your distribution accounts here"] +SIGNING_KEY = "add your signing key here" +NETWORK_PASSPHRASE = "Test SDF Network ; September 2015" + +DIRECT_PAYMENT_SERVER = "http://localhost:8080/sep31" +WEB_AUTH_ENDPOINT = "http://localhost:8080/auth" + +[[CURRENCIES]] +code = "USDC" +issuer = "GBBD47IF6LWK7P7MDEVSCWR7DPUWV3NY3DTQEVFL4NAT4AQH3ZLLFLA5" +status = "test" +is_asset_anchored = false +desc = "USD Coin issued by Circle" + +[DOCUMENTATION] +ORG_NAME = "Your organization" +ORG_URL = "Your website" +ORG_DESCRIPTION = "A description of your organization" +``` + + + +Note that you'll need to create another file for your production deployment that uses the public network's passphrase, your production service URLs, your mainnet distribution accounts and signing key, as well as the mainnet issuing accounts of the assets your service utilizes. + +## Enable Cross Border Payments + +Now you're ready to enable cross-border payments the SEP-31 API. Specify the following in your `dev.assets.yaml` file. + + + +```yaml +# dev.assets.yaml +assets: + - schema: stellar + code: USDC + issuer: GBBD47IF6LWK7P7MDEVSCWR7DPUWV3NY3DTQEVFL4NAT4AQH3ZLLFLA5 + distribution_account: GBLSAHONJRODSFTLOV225NZR4LHICH63RIFQTQN37L5CRTR2IMQ5UEK7 + significant_decimals: 2 + sep31_enabled: true + sep31: + quotes_supported: true + quotes_required: true + fields: + transaction: {} + send: + min_amount: 0 + max_amount: 10000 +``` + + + +The information provided in the `sep31` and `send` objects closely map to the information that will be exposed to the wallet application using the [`GET /info`][sep31-get-info] SEP-31 endpoint. The Anchor Platform also uses this information to validate requests made to your service. `sep31.fields.transaction` should be left empty and will be removed in a future release, but you can adjust the `send.min_amount` and `send.max_amount` values according to your service's limits. + +The `sep31.quotes_supported` and `sep31.quotes_required` determine whether or not sending organizations can and are required to request an FX rate using the [SEP-38 `POST /quote`][sep38-post-quote] endpoint. Almost all senders prefer this approach so that they can communicate the rate to their customers prior to proceeding. + +Add the following variable to your environment file. + + + +```bash +# dev.env +SEP31_ENABLED=true +``` + + + +Senders should now be able to discover, authenticate, and initiate transactions with your service! Run the following command to start the Anchor Platform. + + + +```bash +docker compose up +``` + + + +Check that your API is live. + + + +```bash +curl http://localhost:8080/sep31/info | jq +``` + + + +You should get the following. + + + +```json +{ + "receive": { + "USDC": { + "enabled": true, + "quotes_supported": true, + "quotes_required": true, + "min_amount": 0, + "max_amount": 10000, + "fields": { + "transaction": {} + } + } + } +} +``` + + + +## Enable the Customer KYC API + +Businesses need to collect and validate KYC information on the customers they're facilitating transactions for. Clients determine what KYC information needs to be collected and send that information via a SEP-12 KYC API hosted by the Anchor Platform, but the Anchor Platform never stores personally-identifiable information (PII). Instead, it forwards requests from clients to the business server, and returns the business' responses back to the client, acting as a proxy server. + +See the [Anchor Platform KYC API specification][platform-api-kyc] for details on the endpoints that must be implemented on your business' server. + +To make this API available to clients, lets add the service URL to our Stellar Info File. + + + +```toml +# dev.stellar.toml +KYC_SERVER = "http://localhost:8080/sep12" +``` + + + +Lets enable it in our environment too. + + + +```bash +# dev.env +SEP12_ENABLED=true +``` + + + +Finally, we have to define your business' customer types. Each type of customer requires different a set of KYC information. For example, you can offer your cross-border payments service in two distinct regulatory jurisdictions, so customers in different jurisdictions have different KYC requirements and would be represented using different types. + +:::info + +Currently, customer types must be mutually exclusive, meaning a customer cannot be more than one type. + +This limitation is in place because the Anchor Platform cannot validate whether a customer is approved for a specific type of transaction, such as one sending a large amount. It can only validate that a customer is approved for one of the customer types defined. This limitation will be removed in a future release. + +::: + +In this guide, we'll only have two types, a sending customer type and a receiving customer type. Currently, our customer types are defined in our assets configuration, but this will change in a future release. + + + +```yaml +# dev.assets.yaml +sep31: + sep12: + sender: + types: + sep31-sender: + description: customers sending to recipients + receiver: + types: + sep31-receiver: + description: customers receiving from senders +``` + + + +Let's ping the info endpoint again to verify. After `docker compose up`, run the following command: + + + +```bash +curl http://localhost:8080/sep31/info | jq +``` + + + +You should get the following: + + + +```json +{ + "receive": { + "USDC": { + "enabled": true, + "quotes_supported": true, + "quotes_required": true, + "min_amount": 0, + "max_amount": 10000, + "fields": { + "transaction": {} + }, + "sep12": { + "sender": { + "types": { + "sep31-sender": { + "description": "customers sending to recipients" + } + } + }, + "receiver": { + "types": { + "sep31-receiver": { + "description": "customers receiving from senders" + } + } + } + } + } + } +} +``` + + + +## Enable the RFQ API + +Businesses need to provide their send-side counterparts with a [Rate][get-rates-api] API to check the exchange rates they're offering between the on-chain asset being used for settlement and the fiat asset being used to pay the recipient. If the rate is competitive, senders also need to be able to request a commitment to the rate currently being offered from business for a short period of time. + +The Anchor Platform provides the [SEP-38 RFQ API][sep38] to senders for this purpose. + +To make this API available to clients, lets add the service URL to our Stellar Info File. + + + +```toml +# dev.stellar.toml +DIRECT_PAYMENT_SERVER = "http://localhost:8080/sep31" +WEB_AUTH_ENDPOINT = "http://localhost:8080/auth" +KYC_SERVER = "http://localhost:8080/sep12" +QUOTE_SERVER = "http://localhost:8080/sep38" +``` + + + +Lets enable it in our environment too. + + + +```bash +# dev.env +SEP38_ENABLED=true +``` + + + +We also need to enable USDC to be used in this API, as well as add an off-chain asset it can be exchanged with. + + + +```yaml +# dev.assets.yaml +assets: + - schema: stellar + code: USDC + issuer: GBBD47IF6LWK7P7MDEVSCWR7DPUWV3NY3DTQEVFL4NAT4AQH3ZLLFLA5 + distribution_account: GBLSAHONJRODSFTLOV225NZR4LHICH63RIFQTQN37L5CRTR2IMQ5UEK7 + significant_decimals: 2 + sep31_enabled: true + sep38_enabled: true + send: + min_amount: 0 + max_amount: 10000 + sep31: + quotes_supported: true + quotes_required: true + fields: + transaction: {} + sep12: + sender: + types: + sep31-sender: + description: customers sending to recipients + receiver: + types: + sep31-receiver: + description: customers receiving from senders + sep38: + exchangeable_assets: + - iso4217:BRL + country_codes: + - BRA + - schema: iso4217 + code: BRL + sep38_enabled: true + sep38: + exchangeable_assets: + - stellar:USDC:GBBD47IF6LWK7P7MDEVSCWR7DPUWV3NY3DTQEVFL4NAT4AQH3ZLLFLA5 + country_codes: + - BRA + significant_decimals: 2 + buy_delivery_methods: + - name: PIX + description: Have BRL sent directly to your bank account. +``` + + + +Lets test that your RFQ API is live! Following `docker compose up`: + + + +```bash +curl http://localhost:8080/sep38/info | jq +``` + + + +You should get the following: + + + +```json +{ + "assets": [ + { + "asset": "stellar:USDC:GBBD47IF6LWK7P7MDEVSCWR7DPUWV3NY3DTQEVFL4NAT4AQH3ZLLFLA5" + }, + { + "asset": "iso4217:BRL", + "country_codes": ["BRA"], + "buy_delivery_methods": [ + { + "name": "PIX", + "description": "Have BRL sent directly to your bank account." + } + ] + } + ] +} +``` + + + +## Configure Callback API Authentication + +Just as your business will need to make requests to the Anchor Platform, the Anchor Platform will need to make requests to your business. Let's add authentication to these requests as well. + + + +```bash +# dev.env +CALLBACK_API_BASE_URL=http://server:8081 +CALLBACK_API_AUTH_TYPE=jwt +CALLBACK_API_AUTH_JWT_EXPIRATION_MILLISECONDS=30000 +SECRET_CALLBACK_API_AUTH_SECRET= +``` + + + +`CALLBACK_API_BASE_URL` uses `server` instead of `localhost` as the host because the Anchor Platform will be making requests to your business server from within the local network created by docker compose. When configuring your service in a staging or production environment, make sure to update your service urls. + +We'll define the server that implements the endpoints defined in the Callback API in the following section. + +:::caution + +Note that as of 2.x path segments are not supported in `CALLBACK_API_BASE_URL` (such as `http://server:8081/myPath`). + +::: + +[sep31-get-info]: https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0031.md#get-info +[sep1-ap]: ../sep1/README.mdx +[get-rates-api]: ../../api-reference/callbacks/get-rates.api.mdx +[sep38]: https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0038.md +[sep38-post-quote]: https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0038.md#post-quote +[platform-api-kyc]: ../../api-reference/callbacks/customer/README.mdx diff --git a/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/sep31/getting-started.mdx b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/sep31/getting-started.mdx new file mode 100644 index 000000000..5cc9a6825 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/sep31/getting-started.mdx @@ -0,0 +1,21 @@ +--- +title: Getting Started +sidebar_position: 10 +--- + +This guide will walk you through configuring and integrating with the Anchor Platform for the purpose of building a cross-border payments recieve-side service compatible with [SEP-31][sep-31], the ecosystem's standardized protocol for cross-border payments. + +By leveraging the Anchor Platform's support for SEP-31, businesses make their service compatible with Stellar's existing set of send-side services. + +:::info + +As we improve the documentation, parts of this guide that are relevant to other use cases may be moved into their own sections. + +::: + +Before continuing with this section, make sure that you have already [installed][installation-ap] the Anchor Platform and configured the necessary features required by SEP-31: [SEP-1 (Stellar Info File)][sep1-ap] and [SEP-10 (Stellar Authentication)][sep10-ap]. + +[sep-31]: https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0031.md +[installation-ap]: ../../admin-guide/getting-started.mdx +[sep1-ap]: ../sep1/README.mdx +[sep10-ap]: ../sep10/README.mdx diff --git a/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/sep31/integration.mdx b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/sep31/integration.mdx new file mode 100644 index 000000000..8923934c0 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/sep31/integration.mdx @@ -0,0 +1,694 @@ +--- +title: Integration +sidebar_position: 30 +--- + +import { CodeExample } from "@site/src/components/CodeExample"; + +Integrating with the Anchor Platform for facilitating cross-border payments involves implementing the following, at a minimum: + +- [`GET /customer`][get-customer] & [`PUT /customer`][put-customer] KYC API endpoints to request & collect customers' KYC data +- [`GET /rate`][get-rate] RFQ API endpoint to provide FX rates between the on & off-chain assets supported +- `GET /transactions` requests to fetch updates on the Anchor Platform's transactions' statuses (documentation coming soon) +- [`JSON-RPC`][json-rpc-methods] requests to update the Anchor Platform's transactions' statuses + +The following may also be required depending on your use case: + +- [`GET /fee`][get-fee] if your business wants to provide senders the option to skip the quote creation step +- [`GET /unique_address`][get-unique-address] if your business uses a custody service for on-chain assets +- [`DELETE /customer`][delete-customer] if your business wants or is required to allow senders to request deletion of customer data + +## Create a Business Server + +First, lets create a business server and add it to our docker compose file. + + + +```yaml +version: "3.8" + +services: + sep-server: + image: stellar/anchor-platform:latest + command: --sep-server + env_file: + - ./dev.env + volumes: + - ./config:/home + ports: + - "8080:8080" + depends_on: + - db + platform-server: + image: stellar/anchor-platform:latest + command: --platform-server + env_file: + - ./dev.env + volumes: + - ./config:/home + ports: + - "8085:8085" + depends_on: + - db + + server: + build: . + ports: + - "8081:8081" + env_file: + - ./dev.env + db: + image: postgres:14 + ports: + - "5432:5432" + env_file: + - ./dev.env +``` + + + +Next, create a simple web server using your preferred programming language and a `Dockerfile` that starts the server. `docker compose up` should successfully start all three services. + +This guide does not provide an example implementation of the endpoints, but you can find more information about the request and response schemas in the [Anchor Platform API Reference][ap-api], and the sections below will expand on concepts important to understand when implementing the endpoints. + +## Customer Callback Endpoints + +The Anchor Platform never stores your customers' PII, and instead acts as a proxy server between client applications and your business, forwarding requests and responses to the other party. Currently, requests and responses are almost identical to those defined in the [SEP-12 KYC API specification][sep12]. + +### Identifying Customers + +Customers can be identified using two approaches. + +The first approach uses a Stellar account and memo. When using the Anchor Platform for facilitating cross-border payments, the sending organization uses their own Stellar account, the one used to authenticate via [SEP-10 Stellar Authentication][ap-sep10], when registering customers with your business. Memos are used to distinguish unique customers originating from the same sending organization. + +The second approach uses customer IDs generated by your service. For example, if a sending organization is registering a customer, your business will receive a `PUT /customer` request like the following: + + + +```json +{ + "account": "GDJUOFZGW5WYBK4GIETCSSM6MTTIJ4SUMCQITPTLUWMQ6B4UIX2IEX47", + "memo": "780284017", + "type": "sep31-sender", + "first_name": "John", + "last_name": "Doe", + "email": "johndoe@example.com" +} +``` + + + +In this example, the `GDJ...X47` public key identifies the sending organization, and the `780284017` memo identifies the customer. Memos are usually 64-bit integers, but they can also be other data types, so they should be saved as strings. In response, your business should return a customer ID. + + + +```json +{ + "id": "fb5ddc93-1d5d-490d-ba5f-2c361cea41f7" +} +``` + + + +Your business server can use any identifer for customers as long as it is a string. + +Following the registration of a customer, the sending organization can use either approach when checking the customer's status. For example, you may get a `GET /customer` request like the following: + + + +``` +/customer?account=GDJUOFZGW5WYBK4GIETCSSM6MTTIJ4SUMCQITPTLUWMQ6B4UIX2IEX47&memo=780284017&type=sep31-sender +``` + + + +Or, the sending organziation could use the identifier you returned when they originally registered the customer. + + + +``` +/customer?id=fb5ddc93-1d5d-490d-ba5f-2c361cea41f7&type=sep31-sender +``` + + + +Your business will need to maintain a mapping between the account & memo used to originally register the customer and the ID you return in the response, as well as the KYC data provided. In future iterations of the Anchor Platform, we may maintain this mapping for your business so you only have to work with the IDs you generate. + +### Customer Types + +Your business likely requires different sets of KYC information depending on the type of customer. You can define the labels for each of these customer types in your `dev.assets.yaml` file, and your sending organizations will need to understand which label to use when registering or querying the status of customers. + +In `PUT /customer` requests, you should use the type passed to evaluate whether the sender has provided all of the required fields. In `GET /customer` requests, you should use the type to determine the customer's status. + +### Test with the Demo Wallet + +You can test your implementation with the [Stellar Demo Wallet][demo-wallet] following the steps below. + +1. Select "Generate keypair for new account" +2. Select "Create account" +3. Select "Add Asset" and enter the asset code and the Anchor Platform's home domain, `localhost:8080` +4. Select "Add trustline" +5. Fund your account with a balance of the asset +6. Select "SEP-31 Send" in the dropdown menu + +You should see the demo wallet find your service URLs, authenticate, and check which KYC fields it needs to collect. It should then present a form for you to enter the KYC details for the sender and reciever. + +[![demo wallet after initiating a transaction](/assets/anchor-platform-sep31-demo-wallet-widget.png)](/assets/anchor-platform-sep31-demo-wallet-widget.png) + +Once you've entered in the information requested, it will send that information to the Anchor Platform, which will send it to your business server. Once the demo wallet has the customers' IDs you generated, it will initiate a transaction which should fail. + +## Rate Callback Endpoint + +Once the sending organization has registered the customers involved in the transaction, it will need to request a quote, or FX rate, from your business. The Anchor Platform requests this information from your business server using the [`GET /rate` endpoint][get-rate]. + +### Firm vs. Indicative Quotes + +Requests for quotes will have a `type` parameter that is either [`indicative`][indicative] or [`firm`][firm]. If `type=firm`, your response must include the `id` & `expires_at` date-time field and reserve the liquidity needed to fulfil this quote until the quote expires. If `type=indicative`, do not return `id` or `expires_at` fields because the rate provided will not be used in a transaction. + +Note that the client may request that the quote expires after a specific date-time using the `expires_after` parameter. Your business must honor this request by returning an `expires_at` value that is at or after the requested date-time or reject the request with a 400 Bad Request response, which will be forwarded to the client. + +### Using the Client ID + +Requests may include a `client_id` parameter that identifies the sending organization requesting the rate. You can use this parameter to adhere to the commercial terms agreed upon with that sending organization, such as offering discounted rates. `client_id` may not be present for indicative requests, in which case your market price should be returned. Currently `client_id` will always be the Stellar public key the sending organization used to authenticate with the Anchor Platform. + +### Delivery Methods + +It is common for businesses' rates and fees to differ depending on the payment rails used to send funds to the recipient. If your delivery methods are configured in your `asset.yaml` file, clients will always provide the payment rail they want your business to use for firm quote requests. + +Because this endpoint is currently only used paying out remittances in off-chain assets, the `buy_delivery_method` will be used. If this endpoint is ever used in other transaction flows such as SEP-24 deposits, then `sell_delivery_method` may also be passed for business that support these types of transactions. + +## Fetching Transaction Status Updates + +To facilitate cross-border payments, you'll need to be able to detect when a sending organization has sent your business an on-chain payment and determine which transaction that payment was meant to fulfil. + +The easiest way to do that is to run the Stellar Observer, which will detect these payments and update the corresponding transaction record with information about the payment. Your business can then detect these updates by polling the `GET /transactions` Platform API endpoint. + +### Running the Stellar Observer + +The Stellar Observer monitors the Stellar ledger for payments made to your account(s) and updates the corresponding transaction records with on-chain payment information. To run the observer, add the following to your docker compose file. + + + +```yaml +services: + ... + observer: + image: stellar/anchor-platform:latest + command: --stellar-observer + env_file: + - ./dev.env + volumes: + - ./config:/home +``` + + + +### Polling for Received Payments + +The Stellar Observer makes JSON-RPC requests to the Platform API whenever it detects payments received for transactions initiated by sending organizations, thus updating the transaction's `transfer_received_at` date-time. + +Your business should periodically poll the `GET /transactions` Platform API endpoint to detect these updates. You can refer to the following example: + + + +```bash +curl http://localhost:8080/transactions?sep=31&order_by=transfer_received_at&order=desc +``` + + + +The response will include a list of cross-border payment transactions initiated by sending organizations. This list will be ordered according to the time a payment was received for that transaction. For each transaction returned, your business should check whether or not it has already detected the payment for that transaction. If it has, you have detected all payments made to your account(s). + +## Updating Transaction Via JSON-RPC + +SEP-31 flow diagram defines sequence/rules of the transaction's status transition and a set of JSON-RPC methods that should be called to change that status. You can't define the status you want to set for a specific transaction in your requests. Each JSON-RPC method defines data structures that it expects in the request. If the request doesn't contain required attributes, the Anchor Platform will return an error and won't change the status of the transaction. + +[![sep31 flow](/assets/sep31-transition-diagram.png)](/assets/sep31-transition-diagram.png) + +:::tip + +Statuses in green are mandatory and define the shortest flow. + +Statuses in yellow are optional and can be skipped. + +Statuses in red mean the transaction is in an error status or it has expired. + +::: + +You can create a [template][sep24-integration-make-json-rpc-request] for making a JSON-RPC requests to the Anchor Platform. + +This chapter also contains information about the format of [request][sep24-integration-rpc-request]/[response][sep24-integration-rpc-response] and [error codes][sep24-integration-error-codes] that might be returned by the Anchor Platform. + +### Ready to Receive Funds + +SEP-31 Transactions should initially be in the `pending_sender` status. The Receiving Anchor waits to receive the payment identified by the stellar_memo included in the POST /transactions response. + +Once your business detects that it has received an on-chain payment for a specific transaction, it has to update the transaction status. + + + +```json +// onchain-funds-received.json +[ + { + "id": 1, + "jsonrpc": "2.0", + "method": "notify_onchain_funds_received", + "params": { + "transaction_id": "", + "message": "Onchain funds received", + "stellar_transaction_id": "7...9", + "amount_in": { + "amount": 10 + }, + "amount_out": { + "amount": 9 + }, + "amount_fee": { + "amount": 1 + } + } + } +] +``` + + + +To execute this, you need to run: + + + +```bash +./call-json-rpc.sh onchain-funds-received.json +``` + + + +The transaction status will be changed to `pending_receiver`. + +### Offchain Funds Sent + +To complete the transaction and change its status to `completed`, you need to make a `notify_offchain_funds_sent` JSON-RPC request. + + + +```json +// offchain-funds-sent.json +[ + { + "id": 1, + "jsonrpc": "2.0", + "method": "notify_offchain_funds_sent", + "params": { + "transaction_id": "", + "message": "Offchain funds sent", + "funds_sent_at": "2023-07-04T12:34:56Z", + "external_transaction_id": "a...c" + } + } +] +``` + + + +To execute this, you need to run: + + + +```bash +./call-json-rpc.sh offchain-funds-sent.json +``` + + + +### Offchain Funds Pending + +Another option is to move the transaction's status to `pending_external`. This status means that payment has been submitted to external network, but it is not yet confirmed. + + + +```json +// offchain-funds-pending.json +[ + { + "id": 1, + "jsonrpc": "2.0", + "method": "notify_offchain_funds_pending", + "params": { + "transaction_id": "", + "message": "Offchain funds pending", + "external_transaction_id": "a...c" + } + } +] +``` + + + +To execute this, you need to run: + + + +```bash +./call-json-rpc.sh offchain-funds-pending.json +``` + + + +### Customer Info Needed + +In some cases, the Receiving Anchor might need to request an updated information from the Sending Anchor. For example, the bank tells the Receiving Anchor that the provided Receiving Client's name is incorrect or missing a middle initial. Since this information was sent via SEP-12, the transaction should go into the `pending_customer_info_update` status until the Sending Anchor makes another SEP-12 `PUT /customer` request to update. The Sending Anchor can check which fields need to be updated by making a SEP-12 `GET /customer` request including the id or account & memo parameters. The Receiving Anchor should respond with a `NEEDS_INFO` status and `last_name` included in the fields described. + + + +```json +// pending-customer-info-update.json +[ + { + "id": 1, + "jsonrpc": "2.0", + "method": "pending_customer_info_update", + "params": { + "transaction_id": "", + "message": "Customer info needed" + } + } +] +``` + + + +To execute this, you need to run: + + + +```bash +./call-json-rpc.sh pending-customer-info-update.json +``` + + + +### Customer Info Updated + +After the Sending Anchor has made another SEP-12 `PUT /customer` request to update customer info, the Receiving Anchor should change the status of the transaction to `pending_receiver`. + + + +```json +// notify-customer-info-updated.json +[ + { + "id": 1, + "jsonrpc": "2.0", + "method": "notify_customer_info_updated", + "params": { + "transaction_id": "", + "message": "Customer info updated" + } + } +] +``` + + + +To execute this, you need to run: + + + +```bash +./call-json-rpc.sh notify-customer-info-updated.json +``` + + + +### Do Stellar Refund + +Integration with the custody service allows you to do refund via custody service, such as Fireblocks. + + + +```json +// do-stellar-refund.json +[ + { + "id": 1, + "jsonrpc": "2.0", + "method": "do_stellar_refund", + "params": { + "transaction_id": "", + "message": "Do stellar refund", + "refund": { + "amount": { + "amount": 9, + "asset": "stellar:USDC:GBBD47IF6LWK7P7MDEVSCWR7DPUWV3NY3DTQEVFL4NAT4AQH3ZLLFLA5" + }, + "amount_fee": { + "amount": 1, + "asset": "stellar:USDC:GBBD47IF6LWK7P7MDEVSCWR7DPUWV3NY3DTQEVFL4NAT4AQH3ZLLFLA5" + } + } + } + } +] +``` + + + +To execute this, you need to run: + + + +```bash +./call-json-rpc.sh do-stellar-refund.json +``` + + + +:::note + +You can't do multiple refunds in the SEP-31 flow. For this reason, the total refund amount plus the amount fee should equal `amount_in`. Otherwise, you will get an error. + +::: + +### Refund Sent + +There is a possibility to send all funds back to the `Sending Anchor` (refund). You need to refund the whole sum(full refund). + + + +```json +// refund-sent.json +[ + { + "id": 1, + "jsonrpc": "2.0", + "method": "notify_refund_sent", + "params": { + "transaction_id": "", + "message": "Refund sent", + "refund": { + "id": "1c186184-09ee-486c-82a6-aa7a0ab1119c", + "amount": { + "amount": 10, + "asset": "iso4217:USD" + }, + "amount_fee": { + "amount": 1, + "asset": "iso4217:USD" + } + } + } + } +] +``` + + + +To execute this, you need to run: + + + +```bash +./call-json-rpc.sh refund-sent.json +``` + + + +:::note + +You can't do multiple refunds in SEP-31 flow. For this reason, the amount to refund plus the amount fee should equal `amount_in`. Otherwise, you will get an error. + +::: + +### Transaction Error + +If you encounter an unrecoverable error when processing the transaction, it's required to set the transaction status to `error`. You can use the message field to describe the details of the error. + + + +```json +// transaction-error.json +[ + { + "id": 1, + "jsonrpc": "2.0", + "method": "notify_transaction_error", + "params": { + "transaction_id": "", + "message": "Error occurred" + } + } +] +``` + + + +To execute this, you need to run: + + + +```bash +./call-json-rpc.sh transaction-error.json +``` + + + +:::tip + +If a user has made a transfer, you should do a transaction recovery, and then you can retry processing the transaction or initiate a refund. + +::: + +### Expired Transaction + +Your business may want to expire those transactions that have been abandoned by the user after some time. It's a good practice to clean up inactive transactions in the `incomplete` status. To do so, simply change the transaction's status to `expired`. + + + +```json +// transaction-expired.json +[ + { + "id": 1, + "jsonrpc": "2.0", + "method": "notify_transaction_expired", + "params": { + "transaction_id": "", + "message": "Transaction expired" + } + } +] +``` + + + +To execute this, you need to run: + + + +```bash +./call-json-rpc.sh transaction-expired.json +``` + + + +:::tip + +This JSON-RPC method can't be used after the user has made a transfer. + +::: + +### Transaction Recovery + +The transaction status can be changed from `error/expired` to `pending-anchor`. After recovery, you can refund the received assets or proceed with the processing of the transaction. To recover the transaction, it's necessary to make the following JSON-RPC request: + + + +```json +// transaction-recovery.json +[ + { + "id": 1, + "jsonrpc": "2.0", + "method": "notify_transaction_recovery", + "params": { + "transaction_id": "", + "message": "Transaction recovered" + } + } +] +``` + + + +To execute this, you need to run: + + + +```bash +./call-json-rpc.sh transaction-recovery.json +``` + + + +## Fee Callback Endpoint + +Your business may want to offer sending organizations the option to skip the quote creation process, allowing your business to use a rate determined at the time the funds are paid out to the recipient. In this case, the Anchor Platform will not make a `GET /rate` request, but you will still need to provide the fee your business will charge for these types of transactions using the [`GET /fee`][get-fee] endpoint. + +### Configuration + +You can enable these types of transactions by updating your `assets.yaml` file configuration: + + + +```yaml +assets: + - ... + sep31: + quotes_required: false +``` + + + +## Unique Address Callback Endpoint + +Businesses must provide a unique Stellar account and memo pair for each transaction requested by sending organizations so that the Anchor Platform can identify and map the on-chain payment sent for the specific transaction. The Anchor Platform can generate these account & memo pairs itself, but most businesses use a custodial service to receive on-chain payments. In this case, the business must request the custodian to generate the Stellar account & memo. This is done by using the [`GET /unique_address` endpoint][get-unique-address]. + +### Configuration + +To configure the Anchor Platform to make these requests, add the following to your configuration: + + + +```bash +# dev.env +SEP31_DEPOSIT_INFO_GENERATOR_TYPE=api +``` + + + +:::caution + +This endpoint may be removed during future major version updates of the Anchor Platform, when it adds support for connecting to custodial services and generating these addresses automatically. + +::: + +[ap-api]: ../../README.mdx +[ap-sep10]: ../sep10/README.mdx +[sep12]: https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0012.md +[demo-wallet]: https://demo-wallet.stellar.org +[indicative]: https://www.investopedia.com/terms/i/indicativequote.asp +[firm]: https://www.investopedia.com/terms/f/firmquote.asp +[get-unique-address]: ../../api-reference/callbacks/gen-address.api.mdx +[get-customer]: ../../api-reference/callbacks/get-customer.api.mdx +[put-customer]: ../../api-reference/callbacks/put-customer.api.mdx +[get-rate]: ../../api-reference/callbacks/get-rates.api.mdx +[get-fee]: ../../api-reference/callbacks/get-fee.api.mdx +[get-unique-address]: ../../api-reference/callbacks/gen-address.api.mdx +[put-customer-callback]: ../../api-reference/callbacks/put-customer.api.mdx +[delete-customer]: ../../api-reference/callbacks/del-customer.api.mdx +[json-rpc-methods]: ../../api-reference/rpc/methods/README.mdx +[sep24-integration-make-json-rpc-request]: ../sep24/integration.mdx#making-json-rpc-requests +[sep24-integration-rpc-request]: ../sep24/integration.mdx#json-rpc-request +[sep24-integration-rpc-response]: ../sep24/integration.mdx#json-rpc-response +[sep24-integration-error-codes]: ../sep24/integration.mdx#error-codes diff --git a/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/sep6/README.mdx b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/sep6/README.mdx new file mode 100644 index 000000000..ad44f734d --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/sep6/README.mdx @@ -0,0 +1,12 @@ +--- +title: Programmatic Deposits and Withdrawals +sidebar_position: 65 +--- + +import DocCardList from "@theme/DocCardList"; + +SEP-6 allows for a means by which wallets and/or exchanges interact with an +anchor on behalf of users, never requiring the user to directly interact with +the on & off-ramp. + + diff --git a/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/sep6/configuration.mdx b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/sep6/configuration.mdx new file mode 100644 index 000000000..449ff99b1 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/sep6/configuration.mdx @@ -0,0 +1,237 @@ +--- +title: Configuration +sidebar_position: 20 +--- + +import { CodeExample } from "@site/src/components/CodeExample"; + +# Configuration + +To enable SEP-6 deposits and withdraws, the Anchor Platform must be configured to do the following: + +- Provide the necessary service URLs for SEP-6, 12, & 38 endpoints in the `stellar.toml` file +- Provide information about the on & off-chain assets, as well as the payment rails, supported by your business via SEP-6 and SEP-38 `/info` endpoints +- Support the endpoints and callbacks required to request KYC information and provide exchange rates + +## Enable Programmatic Deposits & Withdrawals + +Add the following variables to your environment file. + + + +```bash +# dev.env +SEP6_ENABLED=true +SEP12_ENABLED=true +SEP38_ENABLED=true +``` + + + +### Modify a Stellar Info File + +Let's modify the `stellar.toml` file created [earlier][sep1-ap]. Wallets need to know that SEP-6 functionality is supported by your business, and they also need to know all the Stellar assets you support. + + + +```toml +# dev.stellar.toml +ACCOUNTS = ["add your public keys for your distribution accounts here"] +SIGNING_KEY = "add your signing key here" +NETWORK_PASSPHRASE = "Test SDF Network ; September 2015" + +TRANSFER_SERVER = "http://localhost:8080/sep6" +WEB_AUTH_ENDPOINT = "http://localhost:8080/auth" +KYC_SERVER = "http://localhost:8080/sep12" +ANCHOR_QUOTE_SERVER = "http://localhost:8080/sep38" + +# Add support for USDC +[[CURRENCIES]] +code = "USDC" +issuer = "GBBD47IF6LWK7P7MDEVSCWR7DPUWV3NY3DTQEVFL4NAT4AQH3ZLLFLA5" +status = "test" +is_asset_anchored = false +desc = "USD Coin issued by Circle" + +[DOCUMENTATION] +ORG_NAME = "Your organization" +ORG_URL = "Your website" +ORG_DESCRIPTION = "A description of your organization" +``` + + + +Note that you will need to create another file for your production deployment that uses the public network's passphrase, your production service URLs, your Mainnet distribution accounts and signing key, as well as the Mainnet issuing accounts of the assets your service utilizes. + +### Modify the Assets Configuration File + +Now you're ready to specify the following in your `dev.assets.yaml` file, and change the values depending on your use case. This example asset file enables support for Circle's USDC and a fiat USD to deposit from and withdraw to. + +The methods specified in the `sep38` sections are methods that will be exposed by the SEP-38 [`GET /info`][sep38] endpoint. + +The methods specified in the `deposit` and `withdraw` sections are the methods that will be exposed by the SEP-6 [`GET /info`][sep-6] endpoint. The methods listed should match the methods defined in the SEP-38 section of the file. + +Also note that fiat assets, those with the `schema: iso4217`, do not need the `sep6_enabled`, `deposit`, or `withdraw` configuration objects specified. In the same way, Stellar assets, those with `schema: stellar`, do not need the `sep38.sell_delivery_methods` or `sep38.buy_delivery_methods` configuration objects specified. + + + +```yaml +assets: + - schema: stellar + code: USDC + issuer: GBBD47IF6LWK7P7MDEVSCWR7DPUWV3NY3DTQEVFL4NAT4AQH3ZLLFLA5 + distribution_account: GBLSAHONJRODSFTLOV225NZR4LHICH63RIFQTQN37L5CRTR2IMQ5UEK7 + significant_decimals: 2 + sep6_enabled: true + sep38_enabled: true + sep38: + exchangeable_assets: + - iso4217:USD + deposit: + enabled: true + methods: + - ACH + withdraw: + enabled: true + methods: + - ACH + - schema: iso4217 + code: USD + significant_decimals: 2 + sep38_enabled: true + sep38: + exchangeable_assets: + - stellar:USDC:GBBD47IF6LWK7P7MDEVSCWR7DPUWV3NY3DTQEVFL4NAT4AQH3ZLLFLA5 + buy_delivery_methods: + - name: ACH + description: ACH debits for US bank accounts + sell_delivery_methods: + - name: ACH + description: ACH credit for US bank accounts + +``` + + + +### Managing Distribution Accounts + +Note that the example above lists a `distribution_account` attribute for the USDC entry. If specified, this account will be provided along with a randomly generated and unique-per-transaction memo to clients as the address to send funds to for withdrawal transactions. The transaction's memo is how you or the Anchor Platform will match the funds received with a transaction record in the Anchor Platform's database. + +If you do not have your own Stellar account and instead use a third party that provides you a Stellar account and memo so they can receive funds on your behalf, such as an exchange or custodian, you should omit the `distribution_account` field from your assets config file. Instead, you'll need to provide the Stellar account and memo you'd like to use to receive funds through a request to the Anchor Platform's [`request_onchain_funds`][request-onchain-funds] on a per-transaction basis. + +To configure the Anchor Platform to expect the Stellar account and memo to be provided via API instead of configured via the assets file, specify the following environment variable. + + + +```bash +# dev.env +SEP6_DEPOSIT_INFO_GENERATOR_TYPE=none +``` + + + +If you use a wallet provider supported by the Anchor Platform's custody service, such as Fireblocks, you can also configure the Anchor Platform to connect directly to your wallet provider to fetch your distribution accounts and memos. If this is configured, the Anchor Platform will also use the wallet provider to send funds to customers. See the [custody services] section for more information about configuring this feature, but first you'll need to specify a different value for the above-mentioned environment variable. + + + +```bash +# dev.env +SEP6_DEPOSIT_INFO_GENERATOR_TYPE=custody +``` + + + +### Enable Callbacks to the Business Server + +Businesses need to collect and validate KYC information on the customers they're facilitating transactions for. Clients ask your business what KYC information needs to be collected and sends that information via the SEP-12 KYC API hosted by the Anchor Platform, but the Anchor Platform never stores personally-identifiable information (PII). Instead, it forwards requests from clients to the business server, and returns the business' responses back to the client, acting as a proxy server. + +Additionally, businesses need to provide clients with a [Rates][get-rates-api] API to check the exchange rates they're offering between the onchain and offchain assets supported by the business. If the rate is competitive, clients also need to be able to request a commitment to the rate currently being offered from business for a short period of time. Similarly to the KYC API, the Anchor Platform makes requests to your business server to fetch exchange rates and quotes and returns them to clients. + +To enable these requests to your business server, first you'll need to add your business server to the docker compose file. Then, to support requests to your business server from the Anchor Platform, you need to enable callbacks. + + + +```bash +# dev.env +CALLBACK_API_BASE_URL=http://business-server:3000/callbacks +CALLBACK_API_AUTH_TYPE=jwt +CALLBACK_API_AUTH_JWT_EXPIRATION_MILLISECONDS=30000 +CALLBACK_API_AUTH_JWT_HTTP_HEADER=Authorization +SECRET_CALLBACK_API_AUTH_SECRET="a secret used to sign JWTs" +``` + + + +The above tells the Anchor Platform to include a JWT, signed with the configured secret, in the `Authorization` header of requests made to `/callbacks/` so your server can authenticate the Anchor Platform before processing requests. + +See the [KYC API][platform-api-kyc] and [Rates API][sep38] for details on the endpoints that must be implemented on your business' server. + +## Test With the Demo Wallet + +Wallets should now be able to discover, authenticate, and initiate transactions with your service! Your project and source files should now look something like this. + + + +``` +β”œβ”€β”€ dev.env +β”œβ”€β”€ docker-compose.yaml +β”œβ”€β”€ config +β”‚ β”œβ”€β”€ dev.assets.yaml +β”‚ β”œβ”€β”€ dev.stellar.toml +``` + + + +Your environment should now look something like the following. + + + +```bash +# dev.env +ASSETS_TYPE=file +ASSETS_VALUE=/home/dev.assets.yaml + +SEP1_ENABLED=true +SEP1_TOML_TYPE=file +SEP1_TOML_VALUE=/home/dev.stellar.toml + +SEP6_ENABLED=true +SEP6_DEPOSIT_INFO_GENERATOR_TYPE=none + +SEP10_ENABLED=true +SEP10_HOME_DOMAIN=localhost:8080 +SECRET_SEP10_SIGNING_SEED="a Stellar private key" +SECRET_SEP10_JWT_SECRET="a secret used to sign JWTs" + +SEP12_ENABLED=true + +SEP38_ENABLED=true + +CALLBACK_API_BASE_URL=http://business-server:3000/callbacks +CALLBACK_API_AUTH_TYPE=jwt +CALLBACK_API_AUTH_JWT_EXPIRATION_MILLISECONDS=30000 +CALLBACK_API_AUTH_JWT_HTTP_HEADER=Authorization +SECRET_CALLBACK_API_AUTH_SECRET="a secret used to sign JWTs" +``` + + + +To test this out, go to the [Stellar Demo Wallet][stellar-demo-wallet]. + +Initiate a deposit transaction by doing the following: + +- Create a new keypair +- Click the "Add Asset" button and enter + - the code of the Stellar asset on your `stellar.toml` file + - your home domain, `localhost:8080` +- Select the dropdown and click "SEP-6 Deposit", then click "Start" + +The demo wallet should be able to find your `stellar.toml` file, authenticate using the Stellar keypair you just created, and initiate a transaction. + +[sep-6]: https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0006.md +[sep1-ap]: ../sep1/README.mdx +[stellar-demo-wallet]: https://demo-wallet.stellar.org/ +[get-rates-api]: ../../api-reference/callbacks/get-rates.api.mdx +[sep38]: https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0038.md +[platform-api-kyc]: ../../api-reference/callbacks/customer/README.mdx +[request-onchain-funds]: ../../api-reference/rpc/methods/request_onchain_funds/README.mdx diff --git a/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/sep6/getting-started.mdx b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/sep6/getting-started.mdx new file mode 100644 index 000000000..c73884f8e --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/sep6/getting-started.mdx @@ -0,0 +1,33 @@ +--- +title: Getting Started +sidebar_position: 10 +--- + +This guide will walk you through configuring and integration with the Anchor Platform for the purpose of build an on & off-ramp service compatible with [SEP-6][sep-6], the ecosystem's standardized protocol for programmatic deposit and withdrawals. + +By leveraging the Anchor Platform's support for SEP-6, businesses make their own on & off-ramp service available as an in-app experience through Stellar-based applications such as wallets and exchanges, extending their reach and connecting with users through the applications they already use. + +Before continuing with this section, make sure that you have already [installed][installation-ap] the Anchor Platform, and configured necessary features, required by SEP-6: [SEP-1 (Stellar Info File)][sep1-ap] and [SEP-10 (Stellar Authentication)][sep10-ap]. + +## The Basic User Experience + +The complete customer experience for a deposit or withdrawal using SEP-6 is as follows: + +1. The customer opens the SEP-6 wallet application of their choice +2. The customer selects an asset to deposit and the wallet finds an anchor (clients could also choose the specific anchor) +3. Once the wallet authenticates with the anchor, the customer begins entering their KYC and transaction information requested by the anchor +4. The wallet provides instructions, and the customer deposits real fiat currency with the anchor (such as bank transfer) +5. Once the wallet receives the deposit, the customer receives the tokenized asset on the Stellar network from the anchor's distribution account + +The customer can then use the digital asset on the Stellar network for remittance, payments, trading, store of value, or another use case not listed here. At some later date, the customer could decide to withdraw their assets from the Stellar network, which would look something like this: + +1. The customer opens their wallet application +2. The customer selects the asset for withdrawal and wallet finds the anchor +3. After authenticating with the anchor, the customer can enter their transaction information and any additional KYC information that wasn't already collected +4. After asking for customer approval, the wallet sends the specified amount of the customer's asset balance to the anchor's distribution account on Stellar +5. Once the anchor receives the payment, the customer receives the withdrawn funds via any method supported by the anchor (such as bank transfer) + +[sep-6]: https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0006.md +[installation-ap]: ../../admin-guide/getting-started.mdx +[sep1-ap]: ../sep1/README.mdx +[sep10-ap]: ../sep10/README.mdx diff --git a/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/sep6/integration.mdx b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/sep6/integration.mdx new file mode 100644 index 000000000..eb5d0ea37 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/admin-guide/sep6/integration.mdx @@ -0,0 +1,971 @@ +--- +title: Integration +sidebar_position: 30 +--- + +import { CodeExample } from "@site/src/components/CodeExample"; +import { AttributeTable } from "@site/src/components/AttributeTable"; +import Security from "../component/security/security.mdx"; +import UsingApiKey from "../component/security/api_key.mdx"; +import UsingJwt from "../component/security/jwt.mdx"; +import Rpc from "../component/rpc/rpc.mdx"; +import RpcRequest from "../component/rpc/request.mdx"; +import RpcResponse from "../component/rpc/response.mdx"; +import RpcError from "../component/rpc/error.mdx"; +import Observer from "../component/observer/observer.mdx"; + +One of the main points of interaction with the Anchor Platform is notifying the Platform about events related to transactions. + +In general, you will want to provide updates for the following events. + +- Your business requires the user to submit KYC information to process a transaction +- Your business updated the in/out/fee amounts for a transaction +- Your business is ready to receive funds from the user +- Your business has received funds from the user +- Your business has sent funds to the user +- Your business has a processed a refund for the user's transaction +- Your business experienced an unexpected error + +This is done by making JSON-RPC requests to the Platform API's endpoint. JSON-RPC requests allow you to update the status of the transaction. To move the transaction to a specific status, it's necessary to make a corresponding JSON-RPC request and pass data that is required by the RPC method. + +The Anchor Platform JSON-RPC API is designed to notify the platform about changes in the status of the transaction. Given that, the API will be called every time a user or the anchor takes any action that progresses the transaction status in the flow. + +You can find out more about transaction flow and statuses in the [SEP-6 protocol document][sep-6]. + +[sep-6]: https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0006.md + +## Securing Platform API + + + +### Using API Key + + + +### Using JWT + + + +## Making JSON-RPC Requests + + + +### JSON-RPC Request + + + +### JSON-RPC Response + + + +### Error Codes + + + +## Updating Deposit (Exchange) Transaction Via JSON-RPC + +SEP-6 deposit flow diagram defines sequences/rules of the transaction's status transition and a set of JSON-RPC method that should be called to change that status. You can't define the status you want to set for a specific transaction in your requests. Each JSON-RPC method defines data structures that it expects in request. If request doesn't contain a required attributes, the Anchor Platform will return and error and won't change status of the transaction. + +The deposit exchange flow is the same as the deposit flow, except the amounts will not need to be recalculated when requesting offchain funds, if the user has provided a firm quote from the anchor. + +[![sep6 deposit flow](/assets/sep6-deposit-flow-diagram.png)](/assets/sep6-deposit-flow-diagram.png) + +:::tip + +Statuses in green are mandatory and define the shortest way. + +Statuses in yellow are optional and can be skipped. + +Statuses in red mean the transaction is in an error status or it has expired. + +::: + +### Verifying KYC Information + +Although Anchor Platform does not require a customer to have their KYC information collected before initiating a deposit, your business may want to collect this information before the customer makes a transfer. By listening to transaction created events, or by polling the [`GET /transactions`][get-transactions] endpoint, you can require determine if a transaction requires the customer to update their information. The required SEP-9 fields can be communicated to the user by returning a `NEEDS_INFO` status with the required fields in the `fields` attribute. + + + +```json +// reuest-customer-info-update.json +[ + { + "id": "1", + "jsonrpc": "2.0", + "method": "request_customer_info_update", + "params": { + "id": "", + "message": "Please update your information to continue" + } + } +] +``` + + + +To execute this, you need to run: + + + +```bash +./call-json-rpc.sh request-customer-info-update.json +``` + + + +### Ready to Receive Funds + +After the user has submitted their KYC information, the anchor can notify the Platform that they are ready to receive funds. The anchor should use the `request_offchain_funds` RPC to provide the final amounts to the user. To do so, make the following JSON-RPC request. + + + +```json +// request-offchain-funds.json +[ + { + "id": 1, + "jsonrpc": "2.0", + "method": "request_offchain_funds", + "params": { + "transaction_id": "", + "message": "Request offchain funds", + "amount_in": { + "amount": 10, + "asset": "iso4217:USD" + }, + "amount_out": { + "amount": 9, + "asset": "stellar:USDC:GBBD47IF6LWK7P7MDEVSCWR7DPUWV3NY3DTQEVFL4NAT4AQH3ZLLFLA5" + }, + "amount_fee": { + "amount": 1, + "asset": "iso4217:USD" + }, + "amount_expected": { + "amount": 10 + }, + "instructions": { + "organization.bank_number": { + "value": "123456789", + "description": "US Bank routing number" + }, + "organization.bank_account_number": { + "value": "123456789", + "description": "US Bank account number" + } + } + } + } +] +``` + + + +- `amount_in` is the amount the user has to send to the business. +- `amount_out` is the amount the user will receive. +- `amount_fee` is the total amount of fees collected by the business. +- `asset` is part of the `amount_x` field and is in a SEP-38 format. In this example, it's set to USD, assuming the user made a bank transfer to the system using USD. +- `instructions` is the set of SEP-9 standard fields that user should use to send funds to the business. In this example, the user should send funds to the bank account with the routing number `123456789` and account number `123456789`. + +Information about amounts (in/out/fee) is required if you want to move the transaction to the `pending_user_transfer_start` status. + +To execute this, you need to run: + + + +```bash +./call-json-rpc.sh request-offchain-funds.json +``` + + + +:::caution + +For exchange deposits with a firm quote (the request is associated with a `quote_id`), no amounts should not be provided. + +::: + +### Funds Received + +If offchain funds were received, you'll want to provide updated transaction information. + + + +```json +// offchain-funds-received.json +[ + { + "id": 1, + "jsonrpc": "2.0", + "method": "notify_offchain_funds_received", + "params": { + "transaction_id": "", + "message": "Offchain funds received", + "funds_received_at": "2023-07-04T12:34:56Z", + "external_transaction_id": "7...9", + "amount_in": { + "amount": 10 + }, + "amount_out": { + "amount": 9 + }, + "amount_fee": { + "amount": 1 + }, + "amount_expected": { + "amount": 10 + } + } + } +] +``` + + + +- `funds_received_at` is the date and time of receiving funds. +- `external_transaction_id` is the ID of transaction on external network. + +The amount fields are optional. If skipped, the values prior to this request will be used. + +To execute this, you need to run: + + + +```bash +./call-json-rpc.sh offchain-funds-received.json +``` + + + +### Waiting For User Funds + +In the real world, the transfer confirmation process may take time. In such cases, transactions should be set to a new status indicating that the confirmation of the transfer has been received but the funds themselves have not been received yet. + + + +```json +// offchain-funds-sent.json +[ + { + "id": 1, + "jsonrpc": "2.0", + "method": "notify_offchain_funds_sent", + "params": { + "transaction_id": "", + "message": "Offchain funds sent", + "funds_received_at": "2023-07-04T12:34:56Z", + "external_transaction_id": "7...9" + } + } +] +``` + + + +To execute this, you need to run: + + + +```bash +./call-json-rpc.sh offchain-funds-sent.json +``` + + + +### Sending Onchain Funds + +Next, send a transaction on the Stellar network to fulfill the user deposit. After the Stellar transaction has been submitted, it's necessary to send the `notify_onchain_funds_sent` JSON-RPC request to notify a user that the funds were successfully sent. + + + +```json +// onchain-funds-sent.json +[ + { + "id": 1, + "jsonrpc": "2.0", + "method": "notify_onchain_funds_sent", + "params": { + "transaction_id": "", + "message": "Onchain funds sent", + "stellar_transaction_id": "7...9" + } + } +] +``` + + + +- `stellar_transaction_id` is the transaction id on Stellar network of the transfer. + +To execute this, you need to run: + + + +```bash +./call-json-rpc.sh onchain-funds-sent.json +``` + + + +After this JSON-RPC request, the transaction will be transferred to the `completed` status. + +### Sending Payment Via Custody Service + +The Anchor Platform provides a possibility to send a payment via custody services, such as [Fireblocks](../custody-services/fireblocks/README.mdx). To make a payment via a custody service, make the following JSON-RPC request. + + + +```json +// do-stellar-payment.json +[ + { + "id": 1, + "jsonrpc": "2.0", + "method": "do_stellar_payment", + "params": { + "transaction_id": "", + "message": "Custody payment started" + } + } +] +``` + + + +To execute this, you need to run: + + + +```bash +./call-json-rpc.sh do-stellar-payment.json +``` + + + +After successful processing of the payment on a custody service, the Anchor Platform will automatically make the `notify_onchain_funds_sent` JSON-RPC request and the status of the transaction will be changed to `completed`. + +:::caution + +A user account may not be ready to receive funds. You can check that the account has established a [trustline](/docs/learn/glossary#trustline). Otherwise, you can set the status of the transaction to the `pending_trust` to indicate that the anchor is waiting for the user to establish the trustline. + +If custody integration is enabled, the Anchor Platform will do this validation for you automatically. + +::: + +### Pending Trust + +This status has to be set if a payment requires an asset trustline that wasn't configured by the user. There are two ways of how the transaction may be moved to the `pending_trust` status. The first one is processing of a payment via custody service in case it detected that the trustline isn't configured. The second one is when the business itself detects that the trustline is missing and wants to notify the user that it has to be configured. To move the transaction to the `pending_trust` status, make the following JSON-RPC request. + + + +```json +// request-trust.json +[ + { + "id": 1, + "jsonrpc": "2.0", + "method": "request_trust", + "params": { + "transaction_id": "", + "message": "Asset trustine not configured" + } + } +] +``` + + + +To execute this, you need to run: + + + +```bash +./call-json-rpc.sh request-trust.json +``` + + + +:::info + +Payment via custody service periodically checks if the trustline was configured. If it was, it will automatically send a payment to a custody service and change the status of the transaction to `pending_stellar`. + +::: + +### Trust Set + +This status has to be set if the business has detected that the trustline was or wasn't configured by user. + + + +```json +// trust-set.json +[ + { + "id": 1, + "jsonrpc": "2.0", + "method": "notify_trust_set", + "params": { + "transaction_id": "", + "message": "Asset trustine set", + "success": "true" + } + } +] +``` + + + +- `success` flag which defines if trustline was or wasn't configured by user + +To execute this, you need to run: + + + +```bash +./call-json-rpc.sh trust-set.json +``` + + + +:::info + +Depending on the `success` flag, the status of the transaction will be changed to `pending_stellar` if the trustline was set, or to `pending_anchor` if it wasn't. + +::: + +### Refund Sent + +Sometimes, funds need to be sent back to the user (refund). You can refund the whole sum (full refund) or do a set of partial refunds back to the `source_account` using the `refund_memo` and `refund_memo_type` associated with the transaction if present. Also, if user sent more money than expected, you can refund a part of the sum back to the user and send the rest as onchain funds. + + + +```json +// refund-sent.json +[ + { + "id": 1, + "jsonrpc": "2.0", + "method": "notify_refund_sent", + "params": { + "transaction_id": "", + "message": "Refund sent", + "refund": { + "id": "1c186184-09ee-486c-82a6-aa7a0ab1119c", + "amount": { + "amount": 10, + "asset": "iso4217:USD" + }, + "amount_fee": { + "amount": 1, + "asset": "iso4217:USD" + } + } + } + } +] +``` + + + +To execute this, you need to run: + + + +```bash +./call-json-rpc.sh refund-sent.json +``` + + + +:::info + +If a sum of refunds is less than `amount_in`, the status of the transaction will be set to `pending_anchor`. Only if the sum of refunds is equal to `amount_in`, the status of the transaction will be set to `refunded`. + +::: + +### Refund Pending + +This is similar to [Refund Sent](#refund-sent), but it handles the case when a refund has been submitted to external network but is not yet confirmed. The status of the transaction is set to `pending_external`. This is the status that will be set when waiting for Bitcoin or other external crypto network to complete a transaction, or when waiting for a bank transfer. + +### Transaction Error + +If you encounter an unrecoverable error when processing the transaction, it's required to set the transaction status to `error`. You can use the message field to describe the error details. + + + +```json +// transaction-error.json +[ + { + "id": 1, + "jsonrpc": "2.0", + "method": "notify_transaction_error", + "params": { + "transaction_id": "", + "message": "Error occurred" + } + } +] +``` + + + +To execute this, you need to run: + + + +```bash +./call-json-rpc.sh transaction-error.json +``` + + + +:::tip + +If a user has made a transfer, you should do a transaction recovery, and then you can retry processing the transaction or initiate a refund. + +::: + +### Expired Transaction + +Your business may want to expire transactions that have been abandoned by the user after some time. It's good practice to clean up inactive transactions in the `incomplete` status. To do so, make the following JSON-RPC request to expire a transaction. + + + +```json +// transaction-expired.json +[ + { + "id": 1, + "jsonrpc": "2.0", + "method": "notify_transaction_expired", + "params": { + "transaction_id": "", + "message": "Transaction expired" + } + } +] +``` + + + +To execute this, you need to run: + + + +```bash +./call-json-rpc.sh transaction-expired.json +``` + + + +:::tip + +This JSON-RPC method can't be used after the user has made a transfer. + +::: + +### Transaction Recovery + +Transaction status can be changed from `error/expired` to `pending_anchor`. After recovery, you can refund the received assets or proceed with processing of the transaction. To recover a transaction, make the following JSON-RPC request. + + + +```json +// transaction-recovery.json +[ + { + "id": 1, + "jsonrpc": "2.0", + "method": "notify_transaction_recovery", + "params": { + "transaction_id": "", + "message": "Transaction recovered" + } + } +] +``` + + + +To execute this, you need to run: + + + +```bash +./call-json-rpc.sh transaction-recovery.json +``` + + + +## Updating Withdrawal (Exchange) Transaction Via JSON-RPC + +The SEP-6 withdrawal flow diagram defines the sequence/rules of the transaction's status transition. You can't define the status you want to set for a specific transaction in your requests. Each JSON-RPC method defines data structures that it expects in request. If request doesn't contain a required attributes, the Anchor Platform will return and error and won't change status of the transaction. + +The withdrawal exchange flow is the same as the withdrawal flow, except the amounts will not need to be recalculated when requesting onchain funds, if the user has provided a firm quote from the anchor. + +[![sep6 withdrawal flow](/assets/sep6-withdrawal-flow-diagram.png)](/assets/sep6-withdrawal-flow-diagram.png) + +:::tip + +Statuses in green are mandatory and define the shortest way. + +Statuses in yellow are optional and can be skipped. + +Statuses in red mean the transaction is in an error status or it has expired. + +::: + +Once the withdrawal flow is finished, implementing the withdrawal is straightforward. Some parts of the flow are similar and can be reused. + +The starting point both for withdrawal and for deposit is the same. + +### Ready to Receive Funds + +Similarly to deposit, the step after KYC has been collected is to notify the user that the anchor is ready to receive funds. However, as your service will be receiving transactions over the Stellar network, the RPC request will be different. The anchor should use the `request_onchain_funds` RPC to provide the final amounts to the user. To do so, make the following JSON-RPC request. + + + +```json +// request-onchain-funds.json +[ + { + "id": 1, + "jsonrpc": "2.0", + "method": "request_onchain_funds", + "params": { + "transaction_id": "", + "message": "Request onchain funds", + "amount_in": { + "amount": 10, + "asset": "stellar:USDC:GBBD47IF6LWK7P7MDEVSCWR7DPUWV3NY3DTQEVFL4NAT4AQH3ZLLFLA5" + }, + "amount_out": { + "amount": 9, + "asset": "iso4217:USD" + }, + "amount_fee": { + "amount": 1, + "asset": "stellar:USDC:GBBD47IF6LWK7P7MDEVSCWR7DPUWV3NY3DTQEVFL4NAT4AQH3ZLLFLA5" + }, + "amount_expected": { + "amount": 10 + }, + "destination_account": "GD...G", + "memo": "12345", + "memo_type": "id" + } + } +] +``` + + + +- `amount_in` is the amount the user has to send to the business. +- `amount_out` is the amount the user will receive. +- `amount_fee` is the total amount of fees collected by the business. +- `asset` is part of the `amount_x` field and is in a SEP-38 format. In this example, it's set to USD, assuming the user made a bank transfer to the system using USD. +- `memo` is the memo the user should use when sending their onchain funds to the anchor. +- `memo_type` is the memo type the user should use when sending their onchain funds to the anchor. +- `destination_account` is the account the user should send the funds to. + +To execute this, you need to run: + + + +```bash +./call-json-rpc.sh request-onchain-funds.json +``` + + + +:::caution + +For exchange withdrawals with a firm quote (the request is associated with a `quote_id`), no amounts should not be provided. + +::: + +:::tip + +Setting `memo`, `memo_type`, and `destination_account` is optional. + +If integration with a third-party custodian is enabled, the Anchor Platform can generate `memo`, `memo_type`, and `destination_address` if a corresponding `deposit_info_generator_type` is chosen. Also, you can provide `memo` and `memo_type` to the request as shown above. Note that the memo must be unique, this is what helps to associate Stellar transactions with SEP transactions. + +If your business manages the assets, the Anchor Platform can generate memos for you. When the status is changed to `pending_user_transfer_start`, the Anchor Platform sets the `memo` and `memo_type` automatically (only if it's not included in the request). + +::: + +:::note + +The Stellar account that will be used to receive funds should be configured. + +::: + +### Funds Received + +If onchain funds were received, you need to provide amounts and change the status of the transaction to `pending_anchor`. + + + +```json +// onchain-funds-received.json +[ + { + "id": 1, + "jsonrpc": "2.0", + "method": "notify_onchain_funds_received", + "params": { + "transaction_id": "", + "message": "Onchain funds received", + "stellar_transaction_id": "7...9", + "amount_in": { + "amount": 10 + }, + "amount_out": { + "amount": 9 + }, + "amount_fee": { + "amount": 1 + } + } + } +] +``` + + + +To execute this, you need to run: + + + +```bash +./call-json-rpc.sh onchain-funds-received.json +``` + + + +:::tip + +This method will be called automatically by the custody server if the custody integration is enabled. + +::: + +### Amount Updated + +If onchain funds were received, but for some reason the `amount_in` differs from specified in the interactive flow (`amount_expected`), you can update `amount_out` and `amount_fee` to make them correspond to the actual `amount_in`. The status of the transaction in this case won't be changed and will be equal to `pending_anchor`. + + + +```json +// amounts-updated.json +[ + { + "id": 1, + "jsonrpc": "2.0", + "method": "notify_amounts_updated", + "params": { + "transaction_id": "", + "message": "Amounts updated", + "amount_out": { + "amount": 9 + }, + "amount_fee": { + "amount": 1 + } + } + } +] +``` + + + +To execute this, you need to run: + + + +```bash +./call-json-rpc.sh amounts-updated.json +``` + + + +:::note + +Only `amount_out` and `amount_fee` can be updated using this JSON-RPC request, and you don't need to specify the assets of the amounts. + +::: + +### Offchain Funds Available + +You can move transaction status to `pending_user_transfer_complete` if offchain funds were sent, and if it's ready for the user / recipient to pick it up. + + + +```json +// offchain-funds-available.json +[ + { + "id": 1, + "jsonrpc": "2.0", + "method": "notify_offchain_funds_available", + "params": { + "transaction_id": "", + "message": "Offchain funds available", + "external_transaction_id": "a...c" + } + } +] +``` + + + +To execute this, you need to run: + + + +```bash +./call-json-rpc.sh offchain-funds-available.json +``` + + + +### Offchain Funds Pending + +Another option is to move the transaction's status to `pending_external`. This status means that the payment has been submitted to an external network, but is not yet confirmed. + + + +```json +// offchain-funds-pending.json +[ + { + "id": 1, + "jsonrpc": "2.0", + "method": "notify_offchain_funds_pending", + "params": { + "transaction_id": "", + "message": "Offchain funds pending", + "external_transaction_id": "a...c" + } + } +] +``` + + + +To execute this, you need to run: + + + +```bash +./call-json-rpc.sh offchain-funds-pending.json +``` + + + +### Offchain Funds Sent + +To complete the transaction and change its status to `completed`, you need to make the `notify_offchain_funds_sent` JSON-RPC request. + + + +```json +// offchain-funds-sent.json +[ + { + "id": 1, + "jsonrpc": "2.0", + "method": "notify_offchain_funds_sent", + "params": { + "transaction_id": "", + "message": "Offchain funds sent", + "funds_sent_at": "2023-07-04T12:34:56Z", + "external_transaction_id": "a...c" + } + } +] +``` + + + +To execute this, you need to run: + + + +```bash +./call-json-rpc.sh offchain-funds-sent.json +``` + + + +### Refund Sent + +The refund logic works in the same way as for the deposit flow. For more details, see [Refund Sent](#refund-sent) of the deposit flow. + +### Sending Refund Via Custody Service + +Integration with a custody service allows you to do a refund via a custody service, such as Fireblocks. + + + +```json +// do-stellar-refund.json +[ + { + "id": 1, + "jsonrpc": "2.0", + "method": "do_stellar_refund", + "params": { + "transaction_id": "", + "message": "Do stellar refund", + "refund": { + "amount": { + "amount": 9, + "asset": "stellar:USDC:GBBD47IF6LWK7P7MDEVSCWR7DPUWV3NY3DTQEVFL4NAT4AQH3ZLLFLA5" + }, + "amount_fee": { + "amount": 1, + "asset": "stellar:USDC:GBBD47IF6LWK7P7MDEVSCWR7DPUWV3NY3DTQEVFL4NAT4AQH3ZLLFLA5" + } + } + } + } +] +``` + + + +To execute this, you need to run: + + + +```bash +./call-json-rpc.sh do-stellar-refund.json +``` + + + +:::note + +Similarly to the deposit flow, you can make a full refund or a set of partial refunds. The transaction will stay in `pending_anchor` status until the sum of refunds is less than `amount_in`. If the sum of refunds is equal to `amount_in`, the Anchor Platform will automatically change the status of the transaction to `refunded`. + +::: + +### Transaction Error + +Works in the same manner as for the deposit flow. For more details, see [Transaction Error](#transaction-error) of the deposit flow. + +### Expired Transaction + +Works in the same manner as for the deposit flow. For more details, see [Expired Transaction](#expired-transaction) of the deposit flow. + +### Transaction Recovery + +Works in the same manner as for the deposit flow. For more details, see [Transaction Recovery](#transaction-recovery) of the deposit flow. + +## Tracking Stellar Transactions + + + +[get-transactions]: ../../api-reference/resources/transactions/README.mdx diff --git a/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/README.mdx b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/README.mdx new file mode 100644 index 000000000..1a9f52ea6 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/README.mdx @@ -0,0 +1,10 @@ +--- +title: API Reference +sidebar_position: 20 +--- + +import DocCardList from "@theme/DocCardList"; + +View all Anchor Platform API information. + + diff --git a/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/callbacks/README.mdx b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/callbacks/README.mdx new file mode 100644 index 000000000..7f0e451ad --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/callbacks/README.mdx @@ -0,0 +1,19 @@ +--- +title: Callbacks +sidebar_position: 40 +--- + +import {MethodTable} from "@site/src/components/MethodTable"; + +The Anchor Platform provides several callback functionalities for your business server. + + + +| | | +| -------------------------------------------------------- | - | +| [Customer](./customer/README.mdx) | | +| [Fee](./fee/README.mdx) | | +| [Rate](./rate/README.mdx) | | +| [Unique address generation](./unique-address/README.mdx) | | + + diff --git a/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/callbacks/customer/README.mdx b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/callbacks/customer/README.mdx new file mode 100644 index 000000000..eeeefd6ae --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/callbacks/customer/README.mdx @@ -0,0 +1,22 @@ +--- +title: Customers +order: 0 +--- + +import {EndpointsTable} from "@site/src/components/EndpointsTable"; + +The Anchor Platform does not store customer KYC data. Instead, the Anchor Platform forwards this data to and requests it from the business. + +The customer callbacks are designed for this purpose. Currently, requests & responses for these endpoints are almost identical to the [SEP-12 KYC API specification][sep-12]. + + + +| | | +| ------ | ---------------------------------------- | +| GET | [/customer](../get-customer.api.mdx) | +| PUT | [/customer](../put-customer.api.mdx) | +| DELETE | [/customer/:id](../del-customer.api.mdx) | + + + +[sep-12]: https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0012.md diff --git a/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/callbacks/event/README.mdx b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/callbacks/event/README.mdx new file mode 100644 index 000000000..b980e37e0 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/callbacks/event/README.mdx @@ -0,0 +1,20 @@ +--- +title: Events +order: 0 +--- + +import {EndpointsTable} from "@site/src/components/EndpointsTable"; + +The Anchor Platform can be configured to notify the business of events, such as a transaction being initiated by a client or a payment being sent to one of the business' distribution accounts. + +Currently, the Anchor Platform takes a fairly unforgiving approach to event delivery, retrying a maximum of three times within three seconds before discarding the event. This will likely change in future releases, but for now, businesses should ensure that they implement a mechanism to recover from missed events. + +For example, if you're using the Anchor Platform's `--stellar-observer` to monitor incoming payments, a cron job can check how long it has been since a transaction was updated as ready to receive funds, and if a reasonable amount of time has passed without receiving funds, it can fetch the latest status of the transaction using the Anchor Platform's `GET /transactions/:id` endpoint to make sure the event was not missed, or continuing processing the transaction if it was. + + + +| | | +| ---- | ------------------------------- | +| POST | [/event](../post-event.api.mdx) | + + diff --git a/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/callbacks/fee/README.mdx b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/callbacks/fee/README.mdx new file mode 100644 index 000000000..3a62a8b6d --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/callbacks/fee/README.mdx @@ -0,0 +1,18 @@ +--- +title: Fees +order: 0 +--- + +import {EndpointsTable} from "@site/src/components/EndpointsTable"; + +The `/fee` is a special endpoint, that is called to fetch fee information for a transaction without a quote. + +For example, if your business supports clients who want to skip the quote creation process and will be using the businesses' market rate. + + + +| | | +| --- | -------------------------- | +| GET | [/fee](../get-fee.api.mdx) | + + diff --git a/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/callbacks/rate/README.mdx b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/callbacks/rate/README.mdx new file mode 100644 index 000000000..af77d97da --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/callbacks/rate/README.mdx @@ -0,0 +1,16 @@ +--- +title: Rates +order: 0 +--- + +import {EndpointsTable} from "@site/src/components/EndpointsTable"; + +Rates endpoint is used to fetch the latest quote for the user request. After the quote is known, the Anchor Platform will forward it to the user in the SEP format. + + + +| | | +| --- | ----------------------------- | +| GET | [/rate](../get-rates.api.mdx) | + + diff --git a/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/callbacks/sidebar.ts b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/callbacks/sidebar.ts new file mode 100644 index 000000000..4cea117b3 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/callbacks/sidebar.ts @@ -0,0 +1,163 @@ +import type { SidebarsConfig } from "@docusaurus/plugin-content-docs"; +const sidebar: SidebarsConfig = { + apisidebar: [{ + type: "doc", + id: "anchor-platform/api-reference/callbacks/synchronous-callbacks-api" + }, { + type: "category", + label: "Unique Address", + items: [{ + type: "doc", + id: "anchor-platform/api-reference/callbacks/gen-address", + label: "Generate Unique Address", + className: "api-method get" + }] + }, { + type: "category", + label: "Fees", + items: [{ + type: "doc", + id: "anchor-platform/api-reference/callbacks/get-fee", + label: "Retrieve Fees", + className: "api-method get" + }] + }, { + type: "category", + label: "Rates", + items: [{ + type: "doc", + id: "anchor-platform/api-reference/callbacks/get-rates", + label: "Retrieve Rates", + className: "api-method get" + }] + }, { + type: "category", + label: "Customers", + items: [{ + type: "doc", + id: "anchor-platform/api-reference/callbacks/get-customer", + label: "Retrieve Customer's Info", + className: "api-method get" + }, { + type: "doc", + id: "anchor-platform/api-reference/callbacks/put-customer", + label: "Create or Update Customer Info", + className: "api-method put" + }, { + type: "doc", + id: "anchor-platform/api-reference/callbacks/del-customer", + label: "Delete Customer Data", + className: "api-method delete" + }] + }, { + type: "category", + label: "SEP-31", + items: [{ + type: "doc", + id: "anchor-platform/api-reference/callbacks/gen-address", + label: "Generate Unique Address", + className: "api-method get" + }, { + type: "doc", + id: "anchor-platform/api-reference/callbacks/get-fee", + label: "Retrieve Fees", + className: "api-method get" + }, { + type: "doc", + id: "anchor-platform/api-reference/callbacks/get-rates", + label: "Retrieve Rates", + className: "api-method get" + }, { + type: "doc", + id: "anchor-platform/api-reference/callbacks/get-customer", + label: "Retrieve Customer's Info", + className: "api-method get" + }, { + type: "doc", + id: "anchor-platform/api-reference/callbacks/put-customer", + label: "Create or Update Customer Info", + className: "api-method put" + }, { + type: "doc", + id: "anchor-platform/api-reference/callbacks/del-customer", + label: "Delete Customer Data", + className: "api-method delete" + }, { + type: "doc", + id: "anchor-platform/api-reference/callbacks/post-event", + label: "Receive an Event", + className: "api-method post" + }] + }, { + type: "category", + label: "SEP-38", + items: [{ + type: "doc", + id: "anchor-platform/api-reference/callbacks/get-rates", + label: "Retrieve Rates", + className: "api-method get" + }] + }, { + type: "category", + label: "SEP-6", + items: [{ + type: "doc", + id: "anchor-platform/api-reference/callbacks/get-customer", + label: "Retrieve Customer's Info", + className: "api-method get" + }, { + type: "doc", + id: "anchor-platform/api-reference/callbacks/put-customer", + label: "Create or Update Customer Info", + className: "api-method put" + }, { + type: "doc", + id: "anchor-platform/api-reference/callbacks/post-event", + label: "Receive an Event", + className: "api-method post" + }] + }, { + type: "category", + label: "SEP-12", + items: [{ + type: "doc", + id: "anchor-platform/api-reference/callbacks/get-customer", + label: "Retrieve Customer's Info", + className: "api-method get" + }, { + type: "doc", + id: "anchor-platform/api-reference/callbacks/put-customer", + label: "Create or Update Customer Info", + className: "api-method put" + }, { + type: "doc", + id: "anchor-platform/api-reference/callbacks/del-customer", + label: "Delete Customer Data", + className: "api-method delete" + }] + }, { + type: "category", + label: "SEP-24", + items: [{ + type: "doc", + id: "anchor-platform/api-reference/callbacks/put-customer", + label: "Create or Update Customer Info", + className: "api-method put" + }, { + type: "doc", + id: "anchor-platform/api-reference/callbacks/post-event", + label: "Receive an Event", + className: "api-method post" + }] + }, { + type: "category", + label: "Events", + items: [{ + type: "doc", + id: "anchor-platform/api-reference/callbacks/post-event", + label: "Receive an Event", + className: "api-method post" + }] + }] +}; +export default sidebar.apisidebar; \ No newline at end of file diff --git a/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/callbacks/unique-address/README.mdx b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/callbacks/unique-address/README.mdx new file mode 100644 index 000000000..add68a3e7 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/callbacks/unique-address/README.mdx @@ -0,0 +1,22 @@ +--- +title: Unique Address +order: 0 +--- + +import {EndpointsTable} from "@site/src/components/EndpointsTable"; + +Unique Address is a unique Stellar address + memo pair that is assigned to a new [SEP-31] transaction. + +When creating SEP-31 transaction, a destination address/memo pair is generated automatically by the Anchor Platform. When monitoring Stellar chain (e.g. via Payment Observer), this unique address is used to map on-chain transfers to the SEP transaction. + +In addition, it's possible to define your own address generator (e.g. you can delegate it to your custodial service). This callback is used to generate such addresses. + + + +| | | +| --- | ----------------------------------------- | +| GET | [/unique_address](../gen-address.api.mdx) | + + + +[sep-31]: https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0031.md diff --git a/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/custody-server/README.mdx b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/custody-server/README.mdx new file mode 100644 index 000000000..738110160 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/custody-server/README.mdx @@ -0,0 +1,19 @@ +--- +title: Custody Server +sidebar_position: 50 +--- + +import {MethodTable} from "@site/src/components/MethodTable"; + +The Custody Server provides a set of endpoints to interact with custody services, such as Fireblocks. + + + +| | | +| -------------------------------------------------------- | - | +| [Custody Transaction](./custody-transactions/README.mdx) | | +| [Payment](./payments/README.mdx) | | +| [Refund](./refunds/README.mdx) | | +| [Unique address generation](./unique-address/README.mdx) | | + + diff --git a/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/custody-server/custody-transactions/README.mdx b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/custody-server/custody-transactions/README.mdx new file mode 100644 index 000000000..9028076dc --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/custody-server/custody-transactions/README.mdx @@ -0,0 +1,16 @@ +--- +title: Custody Transactions +order: 0 +--- + +import {EndpointsTable} from "@site/src/components/EndpointsTable"; + +Custody Server creates custody transaction record in DB. + + + +| | | +| ---- | ------------------------------------------------------ | +| POST | [/transactions](../create-custody-transaction.api.mdx) | + + diff --git a/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/custody-server/payments/README.mdx b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/custody-server/payments/README.mdx new file mode 100644 index 000000000..68f1f7ce6 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/custody-server/payments/README.mdx @@ -0,0 +1,16 @@ +--- +title: Payments +order: 0 +--- + +import {EndpointsTable} from "@site/src/components/EndpointsTable"; + +Custody Server calls the configured custody service to send payment. + + + +| | | +| ---- | ----------------------------------------------------- | +| POST | [/transactions/:id/payments](../send-payment.api.mdx) | + + diff --git a/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/custody-server/refunds/README.mdx b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/custody-server/refunds/README.mdx new file mode 100644 index 000000000..0807b3d3c --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/custody-server/refunds/README.mdx @@ -0,0 +1,16 @@ +--- +title: Refunds +order: 0 +--- + +import {EndpointsTable} from "@site/src/components/EndpointsTable"; + +Custody Server calls the configured custody service to send refund. + + + +| | | +| ---- | --------------------------------------------------- | +| POST | [/transactions/:id/refunds](../send-refund.api.mdx) | + + diff --git a/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/custody-server/sidebar.ts b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/custody-server/sidebar.ts new file mode 100644 index 000000000..4603429ff --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/custody-server/sidebar.ts @@ -0,0 +1,116 @@ +import type { SidebarsConfig } from "@docusaurus/plugin-content-docs"; +const sidebar: SidebarsConfig = { + apisidebar: [{ + type: "doc", + id: "anchor-platform/api-reference/custody-server/custody-server-api" + }, { + type: "category", + label: "Custody Transactions", + items: [{ + type: "doc", + id: "anchor-platform/api-reference/custody-server/create-custody-transaction", + label: "Create Custody Transaction", + className: "api-method post" + }] + }, { + type: "category", + label: "Payments", + items: [{ + type: "doc", + id: "anchor-platform/api-reference/custody-server/send-payment", + label: "Send Payment", + className: "api-method post" + }] + }, { + type: "category", + label: "Refunds", + items: [{ + type: "doc", + id: "anchor-platform/api-reference/custody-server/send-refund", + label: "Send Refund", + className: "api-method post" + }] + }, { + type: "category", + label: "Unique Address", + items: [{ + type: "doc", + id: "anchor-platform/api-reference/custody-server/generate-unique-address", + label: "Generate Unique Address", + className: "api-method post" + }] + }, { + type: "category", + label: "SEP-6", + items: [{ + type: "doc", + id: "anchor-platform/api-reference/custody-server/create-custody-transaction", + label: "Create Custody Transaction", + className: "api-method post" + }, { + type: "doc", + id: "anchor-platform/api-reference/custody-server/send-payment", + label: "Send Payment", + className: "api-method post" + }, { + type: "doc", + id: "anchor-platform/api-reference/custody-server/send-refund", + label: "Send Refund", + className: "api-method post" + }, { + type: "doc", + id: "anchor-platform/api-reference/custody-server/generate-unique-address", + label: "Generate Unique Address", + className: "api-method post" + }] + }, { + type: "category", + label: "SEP-24", + items: [{ + type: "doc", + id: "anchor-platform/api-reference/custody-server/create-custody-transaction", + label: "Create Custody Transaction", + className: "api-method post" + }, { + type: "doc", + id: "anchor-platform/api-reference/custody-server/send-payment", + label: "Send Payment", + className: "api-method post" + }, { + type: "doc", + id: "anchor-platform/api-reference/custody-server/send-refund", + label: "Send Refund", + className: "api-method post" + }, { + type: "doc", + id: "anchor-platform/api-reference/custody-server/generate-unique-address", + label: "Generate Unique Address", + className: "api-method post" + }] + }, { + type: "category", + label: "SEP-31", + items: [{ + type: "doc", + id: "anchor-platform/api-reference/custody-server/create-custody-transaction", + label: "Create Custody Transaction", + className: "api-method post" + }, { + type: "doc", + id: "anchor-platform/api-reference/custody-server/send-payment", + label: "Send Payment", + className: "api-method post" + }, { + type: "doc", + id: "anchor-platform/api-reference/custody-server/send-refund", + label: "Send Refund", + className: "api-method post" + }, { + type: "doc", + id: "anchor-platform/api-reference/custody-server/generate-unique-address", + label: "Generate Unique Address", + className: "api-method post" + }] + }] +}; +export default sidebar.apisidebar; \ No newline at end of file diff --git a/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/custody-server/unique-address/README.mdx b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/custody-server/unique-address/README.mdx new file mode 100644 index 000000000..e734eaf4a --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/custody-server/unique-address/README.mdx @@ -0,0 +1,16 @@ +--- +title: Unique Address +order: 0 +--- + +import {EndpointsTable} from "@site/src/components/EndpointsTable"; + +Custody Server calls the configured custody service to generate deposit address and memo. + + + +| | | +| ---- | -------------------------------------------------------------- | +| POST | [/assets/:asset/addresses](../generate-unique-address.api.mdx) | + + diff --git a/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/resources/README.mdx b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/resources/README.mdx new file mode 100644 index 000000000..82bf8e40a --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/resources/README.mdx @@ -0,0 +1,16 @@ +--- +title: Resources +sidebar_position: 30 +--- + +import {MethodTable} from "@site/src/components/MethodTable"; + +Data on the Anchor Platform is organized according to resources. Each resource has several different endpoints. + + + +| | | +| ----------------------------------------- | - | +| [Transactions](./transactions/README.mdx) | | + + diff --git a/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/resources/sidebar.ts b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/resources/sidebar.ts new file mode 100644 index 000000000..b20829f99 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/resources/sidebar.ts @@ -0,0 +1,64 @@ +import type { SidebarsConfig } from "@docusaurus/plugin-content-docs"; +const sidebar: SidebarsConfig = { + apisidebar: [{ + type: "doc", + id: "anchor-platform/api-reference/resources/platform-api" + }, { + type: "category", + label: "Transactions", + items: [{ + type: "doc", + id: "anchor-platform/api-reference/resources/get-transactions", + label: "Retrieve a List of Transactions", + className: "api-method get" + }, { + type: "doc", + id: "anchor-platform/api-reference/resources/get-transaction", + label: "Retrieve a Transaction", + className: "api-method get" + }] + }, { + type: "category", + label: "SEP-6", + items: [{ + type: "doc", + id: "anchor-platform/api-reference/resources/get-transactions", + label: "Retrieve a List of Transactions", + className: "api-method get" + }, { + type: "doc", + id: "anchor-platform/api-reference/resources/get-transaction", + label: "Retrieve a Transaction", + className: "api-method get" + }] + }, { + type: "category", + label: "SEP-24", + items: [{ + type: "doc", + id: "anchor-platform/api-reference/resources/get-transactions", + label: "Retrieve a List of Transactions", + className: "api-method get" + }, { + type: "doc", + id: "anchor-platform/api-reference/resources/get-transaction", + label: "Retrieve a Transaction", + className: "api-method get" + }] + }, { + type: "category", + label: "SEP-31", + items: [{ + type: "doc", + id: "anchor-platform/api-reference/resources/get-transactions", + label: "Retrieve a List of Transactions", + className: "api-method get" + }, { + type: "doc", + id: "anchor-platform/api-reference/resources/get-transaction", + label: "Retrieve a Transaction", + className: "api-method get" + }] + }] +}; +export default sidebar.apisidebar; \ No newline at end of file diff --git a/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/resources/transactions/README.mdx b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/resources/transactions/README.mdx new file mode 100644 index 000000000..94d0dddf2 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/resources/transactions/README.mdx @@ -0,0 +1,18 @@ +--- +title: Transactions +--- + +import {EndpointsTable} from "@site/src/components/EndpointsTable"; + +Transactions are representations of a SEP transaction. It holds information about the protocol being used, and all necessary information passed by an external party (such as wallet or an anchor). + +Should not be confused with stellar [transactions](/docs/learn/glossary#transaction). + + + +| | | +| --- | ----------------------------------------------- | +| GET | [/transactions/:id](../get-transaction.api.mdx) | +| GET | [/transactions/](../get-transactions.api.mdx) | + + diff --git a/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/rpc/README.mdx b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/rpc/README.mdx new file mode 100644 index 000000000..0fef3870b --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/rpc/README.mdx @@ -0,0 +1,11 @@ +--- +title: JSON-RPC API +sidebar_position: 60 +--- + +import DocCardList from "@theme/DocCardList"; + +Interact with your Anchor Platform instance through the use of lightweight, +easy-to-use RPC requests. + + diff --git a/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/rpc/methods/README.mdx b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/rpc/methods/README.mdx new file mode 100644 index 000000000..1fc1ddbd3 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/rpc/methods/README.mdx @@ -0,0 +1,42 @@ +--- +title: JSON-RPC Methods +order: 20 +sidebar_label: Methods +--- + +import {EndpointsTable} from "@site/src/components/EndpointsTable"; + +This section lists the Anchor Platform JSON-RPC API methods that should be called by Stellar clients to update status of the transaction. + +The OpenRPC Specification for JSON-RPC API is available [here](https://playground.open-rpc.org/?schemaUrl=https://raw.githubusercontent.com/stellar/stellar-docs/main/static/assets/rpc-methods/open-rpc.json). + +Postman collection is available [here](https://documenter.getpostman.com/view/9257637/2s9Y5U1kra) + + + +| | | +| - | --------------------------------------------------------------------------------- | +| | [notify_interactive_flow_completed](notify_interactive_flow_completed/README.mdx) | +| | [request_offchain_funds](request_offchain_funds/README.mdx) | +| | [request_onchain_funds](request_onchain_funds/README.mdx) | +| | [notify_offchain_funds_received](notify_offchain_funds_received/README.mdx) | +| | [notify_onchain_funds_received](notify_onchain_funds_received/README.mdx) | +| | [notify_amounts_updated](notify_amounts_updated/README.mdx) | +| | [notify_refund_pending](notify_refund_pending/README.mdx) | +| | [notify_refund_sent](notify_refund_sent/README.mdx) | +| | [do_stellar_payment](do_stellar_payment/README.mdx) | +| | [do_stellar_refund](do_stellar_refund/README.mdx) | +| | [notify_onchain_funds_sent](notify_onchain_funds_sent/README.mdx) | +| | [notify_offchain_funds_sent](notify_offchain_funds_sent/README.mdx) | +| | [notify_offchain_funds_available](notify_offchain_funds_available/README.mdx) | +| | [notify_offchain_funds_pending](notify_offchain_funds_pending/README.mdx) | +| | [request_trust](request_trust/README.mdx) | +| | [notify_trust_set](notify_trust_set/README.mdx) | +| | [request_customer_info_update](request_customer_info_update/README.mdx) | +| | [notify_customer_info_updated](notify_customer_info_updated/README.mdx) | +| | [notify_transaction_error](notify_transaction_error/README.mdx) | +| | [notify_transaction_expired](notify_transaction_expired/README.mdx) | +| | [notify_transaction_recovery](notify_transaction_recovery/README.mdx) | +| | [notify_transaction_on_hold](notify_transaction_on_hold/README.mdx) | + + diff --git a/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/rpc/methods/do_stellar_payment/README.mdx b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/rpc/methods/do_stellar_payment/README.mdx new file mode 100644 index 000000000..03cac2a8c --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/rpc/methods/do_stellar_payment/README.mdx @@ -0,0 +1,30 @@ +--- +title: do_stellar_payment +order: 30 +hide_title: true +--- + +import {RpcMethod} from "@site/src/components/RpcMethod"; +import {CodeFromFileExample} from "@site/src/components/CodeFromFileExample"; + + +
+

Example

+

Request

+ + +```json + +``` + + + +
+

Response

+ + +```json + +``` + + diff --git a/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/rpc/methods/do_stellar_refund/README.mdx b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/rpc/methods/do_stellar_refund/README.mdx new file mode 100644 index 000000000..56a4c4af9 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/rpc/methods/do_stellar_refund/README.mdx @@ -0,0 +1,30 @@ +--- +title: do_stellar_refund +order: 30 +hide_title: true +--- + +import { RpcMethod } from "@site/src/components/RpcMethod"; +import {CodeFromFileExample} from "@site/src/components/CodeFromFileExample"; + + +
+

Example

+

Request

+ + +```json + +``` + + + +
+

Response

+ + +```json + +``` + + diff --git a/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/rpc/methods/notify_amounts_updated/README.mdx b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/rpc/methods/notify_amounts_updated/README.mdx new file mode 100644 index 000000000..e9912b29d --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/rpc/methods/notify_amounts_updated/README.mdx @@ -0,0 +1,30 @@ +--- +title: notify_amounts_updated +order: 30 +hide_title: true +--- + +import { RpcMethod } from "@site/src/components/RpcMethod"; +import {CodeFromFileExample} from "@site/src/components/CodeFromFileExample"; + + +
+

Example

+

Request

+ + +```json + +``` + + + +
+

Response

+ + +```json + +``` + + diff --git a/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/rpc/methods/notify_customer_info_updated/README.mdx b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/rpc/methods/notify_customer_info_updated/README.mdx new file mode 100644 index 000000000..6beb12380 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/rpc/methods/notify_customer_info_updated/README.mdx @@ -0,0 +1,30 @@ +--- +title: notify_customer_info_updated +order: 30 +hide_title: true +--- + +import { RpcMethod } from "@site/src/components/RpcMethod"; +import {CodeFromFileExample} from "@site/src/components/CodeFromFileExample"; + + +
+

Example

+

Request

+ + +```json + +``` + + + +
+

Response

+ + +```json + +``` + + diff --git a/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/rpc/methods/notify_interactive_flow_completed/README.mdx b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/rpc/methods/notify_interactive_flow_completed/README.mdx new file mode 100644 index 000000000..0599c2131 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/rpc/methods/notify_interactive_flow_completed/README.mdx @@ -0,0 +1,30 @@ +--- +title: notify_interactive_flow_completed +order: 30 +hide_title: true +--- + +import { RpcMethod } from "@site/src/components/RpcMethod"; +import {CodeFromFileExample} from "@site/src/components/CodeFromFileExample"; + + +
+

Example

+

Request

+ + +```json + +``` + + + +
+

Response

+ + +```json + +``` + + diff --git a/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/rpc/methods/notify_offchain_funds_available/README.mdx b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/rpc/methods/notify_offchain_funds_available/README.mdx new file mode 100644 index 000000000..39f0e45f0 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/rpc/methods/notify_offchain_funds_available/README.mdx @@ -0,0 +1,30 @@ +--- +title: notify_offchain_funds_available +order: 30 +hide_title: true +--- + +import { RpcMethod } from "@site/src/components/RpcMethod"; +import {CodeFromFileExample} from "@site/src/components/CodeFromFileExample"; + + +
+

Example

+

Request

+ + +```json + +``` + + + +
+

Response

+ + +```json + +``` + + diff --git a/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/rpc/methods/notify_offchain_funds_pending/README.mdx b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/rpc/methods/notify_offchain_funds_pending/README.mdx new file mode 100644 index 000000000..efa3bac15 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/rpc/methods/notify_offchain_funds_pending/README.mdx @@ -0,0 +1,30 @@ +--- +title: notify_offchain_funds_pending +order: 30 +hide_title: true +--- + +import { RpcMethod } from "@site/src/components/RpcMethod"; +import {CodeFromFileExample} from "@site/src/components/CodeFromFileExample"; + + +
+

Example

+

Request

+ + +```json + +``` + + + +
+

Response

+ + +```json + +``` + + diff --git a/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/rpc/methods/notify_offchain_funds_received/README.mdx b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/rpc/methods/notify_offchain_funds_received/README.mdx new file mode 100644 index 000000000..c6741c8b0 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/rpc/methods/notify_offchain_funds_received/README.mdx @@ -0,0 +1,30 @@ +--- +title: notify_offchain_funds_received +order: 30 +hide_title: true +--- + +import { RpcMethod } from "@site/src/components/RpcMethod"; +import {CodeFromFileExample} from "@site/src/components/CodeFromFileExample"; + + +
+

Example

+

Request

+ + +```json + +``` + + + +
+

Response

+ + +```json + +``` + + diff --git a/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/rpc/methods/notify_offchain_funds_sent/README.mdx b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/rpc/methods/notify_offchain_funds_sent/README.mdx new file mode 100644 index 000000000..3389b301b --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/rpc/methods/notify_offchain_funds_sent/README.mdx @@ -0,0 +1,30 @@ +--- +title: notify_offchain_funds_sent +order: 30 +hide_title: true +--- + +import { RpcMethod } from "@site/src/components/RpcMethod"; +import {CodeFromFileExample} from "@site/src/components/CodeFromFileExample"; + + +
+

Example

+

Request

+ + +```json + +``` + + + +
+

Response

+ + +```json + +``` + + diff --git a/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/rpc/methods/notify_onchain_funds_received/README.mdx b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/rpc/methods/notify_onchain_funds_received/README.mdx new file mode 100644 index 000000000..d337e22bd --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/rpc/methods/notify_onchain_funds_received/README.mdx @@ -0,0 +1,30 @@ +--- +title: notify_onchain_funds_received +order: 30 +hide_title: true +--- + +import { RpcMethod } from "@site/src/components/RpcMethod"; +import {CodeFromFileExample} from "@site/src/components/CodeFromFileExample"; + + +
+

Example

+

Request

+ + +```json + +``` + + + +
+

Response

+ + +```json + +``` + + diff --git a/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/rpc/methods/notify_onchain_funds_sent/README.mdx b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/rpc/methods/notify_onchain_funds_sent/README.mdx new file mode 100644 index 000000000..3aae49924 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/rpc/methods/notify_onchain_funds_sent/README.mdx @@ -0,0 +1,30 @@ +--- +title: notify_onchain_funds_sent +order: 30 +hide_title: true +--- + +import { RpcMethod } from "@site/src/components/RpcMethod"; +import {CodeFromFileExample} from "@site/src/components/CodeFromFileExample"; + + +
+

Example

+

Request

+ + +```json + +``` + + + +
+

Response

+ + +```json + +``` + + diff --git a/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/rpc/methods/notify_refund_pending/README.mdx b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/rpc/methods/notify_refund_pending/README.mdx new file mode 100644 index 000000000..834551555 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/rpc/methods/notify_refund_pending/README.mdx @@ -0,0 +1,30 @@ +--- +title: notify_refund_pending +order: 30 +hide_title: true +--- + +import { RpcMethod } from "@site/src/components/RpcMethod"; +import {CodeFromFileExample} from "@site/src/components/CodeFromFileExample"; + + +
+

Example

+

Request

+ + +```json + +``` + + + +
+

Response

+ + +```json + +``` + + diff --git a/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/rpc/methods/notify_refund_sent/README.mdx b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/rpc/methods/notify_refund_sent/README.mdx new file mode 100644 index 000000000..e9d34565e --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/rpc/methods/notify_refund_sent/README.mdx @@ -0,0 +1,30 @@ +--- +title: notify_refund_sent +order: 30 +hide_title: true +--- + +import { RpcMethod } from "@site/src/components/RpcMethod"; +import {CodeFromFileExample} from "@site/src/components/CodeFromFileExample"; + + +
+

Example

+

Request

+ + +```json + +``` + + + +
+

Response

+ + +```json + +``` + + diff --git a/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/rpc/methods/notify_transaction_error/README.mdx b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/rpc/methods/notify_transaction_error/README.mdx new file mode 100644 index 000000000..5f291983e --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/rpc/methods/notify_transaction_error/README.mdx @@ -0,0 +1,30 @@ +--- +title: notify_transaction_error +order: 30 +hide_title: true +--- + +import { RpcMethod } from "@site/src/components/RpcMethod"; +import {CodeFromFileExample} from "@site/src/components/CodeFromFileExample"; + + +
+

Example

+

Request

+ + +```json + +``` + + + +
+

Response

+ + +```json + +``` + + diff --git a/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/rpc/methods/notify_transaction_expired/README.mdx b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/rpc/methods/notify_transaction_expired/README.mdx new file mode 100644 index 000000000..babcc93f4 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/rpc/methods/notify_transaction_expired/README.mdx @@ -0,0 +1,30 @@ +--- +title: notify_transaction_expired +order: 30 +hide_title: true +--- + +import { RpcMethod } from "@site/src/components/RpcMethod"; +import {CodeFromFileExample} from "@site/src/components/CodeFromFileExample"; + + +
+

Example

+

Request

+ + +```json + +``` + + + +
+

Response

+ + +```json + +``` + + diff --git a/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/rpc/methods/notify_transaction_on_hold/README.mdx b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/rpc/methods/notify_transaction_on_hold/README.mdx new file mode 100644 index 000000000..fb363f96d --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/rpc/methods/notify_transaction_on_hold/README.mdx @@ -0,0 +1,30 @@ +--- +title: notify_transaction_on_hold +order: 30 +hide_title: true +--- + +import { RpcMethod } from "@site/src/components/RpcMethod"; +import {CodeFromFileExample} from "@site/src/components/CodeFromFileExample"; + + +
+

Example

+

Request

+ + +```json + +``` + + + +
+

Response

+ + +```json + +``` + + diff --git a/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/rpc/methods/notify_transaction_recovery/README.mdx b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/rpc/methods/notify_transaction_recovery/README.mdx new file mode 100644 index 000000000..c3247e813 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/rpc/methods/notify_transaction_recovery/README.mdx @@ -0,0 +1,30 @@ +--- +title: notify_transaction_recovery +order: 30 +hide_title: true +--- + +import { RpcMethod } from "@site/src/components/RpcMethod"; +import {CodeFromFileExample} from "@site/src/components/CodeFromFileExample"; + + +
+

Example

+

Request

+ + +```json + +``` + + + +
+

Response

+ + +```json + +``` + + diff --git a/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/rpc/methods/notify_trust_set/README.mdx b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/rpc/methods/notify_trust_set/README.mdx new file mode 100644 index 000000000..a3c2fb00e --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/rpc/methods/notify_trust_set/README.mdx @@ -0,0 +1,30 @@ +--- +title: notify_trust_set +order: 30 +hide_title: true +--- + +import { RpcMethod } from "@site/src/components/RpcMethod"; +import {CodeFromFileExample} from "@site/src/components/CodeFromFileExample"; + + +
+

Example

+

Request

+ + +```json + +``` + + + +
+

Response

+ + +```json + +``` + + diff --git a/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/rpc/methods/request_customer_info_update/README.mdx b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/rpc/methods/request_customer_info_update/README.mdx new file mode 100644 index 000000000..5ef039b1c --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/rpc/methods/request_customer_info_update/README.mdx @@ -0,0 +1,30 @@ +--- +title: request_customer_info_update +order: 30 +hide_title: true +--- + +import { RpcMethod } from "@site/src/components/RpcMethod"; +import {CodeFromFileExample} from "@site/src/components/CodeFromFileExample"; + + +
+

Example

+

Request

+ + +```json + +``` + + + +
+

Response

+ + +```json + +``` + + diff --git a/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/rpc/methods/request_offchain_funds/README.mdx b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/rpc/methods/request_offchain_funds/README.mdx new file mode 100644 index 000000000..52c1d87f1 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/rpc/methods/request_offchain_funds/README.mdx @@ -0,0 +1,30 @@ +--- +title: request_offchain_funds +order: 30 +hide_title: true +--- + +import { RpcMethod } from "@site/src/components/RpcMethod"; +import {CodeFromFileExample} from "@site/src/components/CodeFromFileExample"; + + +
+

Example

+

Request

+ + +```json + +``` + + + +
+

Response

+ + +```json + +``` + + diff --git a/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/rpc/methods/request_onchain_funds/README.mdx b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/rpc/methods/request_onchain_funds/README.mdx new file mode 100644 index 000000000..c44ad5460 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/rpc/methods/request_onchain_funds/README.mdx @@ -0,0 +1,30 @@ +--- +title: request_onchain_funds +order: 30 +hide_title: true +--- + +import { RpcMethod } from "@site/src/components/RpcMethod"; +import {CodeFromFileExample} from "@site/src/components/CodeFromFileExample"; + + +
+

Example

+

Request

+ + +```json + +``` + + + +
+

Response

+ + +```json + +``` + + diff --git a/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/rpc/methods/request_trust/README.mdx b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/rpc/methods/request_trust/README.mdx new file mode 100644 index 000000000..08788f287 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/rpc/methods/request_trust/README.mdx @@ -0,0 +1,30 @@ +--- +title: request_trust +order: 30 +hide_title: true +--- + +import { RpcMethod } from "@site/src/components/RpcMethod"; +import {CodeFromFileExample} from "@site/src/components/CodeFromFileExample"; + + +
+

Example

+

Request

+ + +```json + +``` + + + +
+

Response

+ + +```json + +``` + + diff --git a/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/rpc/overview.mdx b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/rpc/overview.mdx new file mode 100644 index 000000000..7ccb3e5bf --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/rpc/overview.mdx @@ -0,0 +1,18 @@ +--- +title: Overview +sidebar_position: 60 +--- + +JSON-RPC is a stateless, light-weight remote procedure call (RPC) protocol. + +It's simple and easy to use, as it uses a single HTTP endpoint and a JSON object that contains the method name and parameters. +It is transport agnostic in that the concepts can be used within the same process, over sockets, over http, or in many various message passing environments. +It uses [JSON](http://www.json.org/) ([RFC 4627](http://www.ietf.org/rfc/rfc4627.txt)) as data format. + +:::note + +All member names exchanged between the Client and the Server that are considered for matching of any kind should be considered to be case-sensitive. + +::: + +You can read more about JSON-RPC protocol [here](https://www.jsonrpc.org/specification). diff --git a/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/rpc/sidebar.js b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/rpc/sidebar.js new file mode 100644 index 000000000..a59f2c65c --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs-platforms/current/anchor-platform/api-reference/rpc/sidebar.js @@ -0,0 +1,57 @@ +module.exports = [ + { + type: 'doc', + id: 'anchor-platform/rpc/rpc-api', + }, + { + type: 'category', + label: 'Methods', + link: { + type: 'generated-index', + title: 'Methods', + slug: '/category/anchor-platform/rpc/methods', + }, + items: [ + { + type: 'doc', + id: 'anchor-platform/rpc/notify_interactive_flow_completed', + label: 'Interactive flow completed', + className: 'api-method patch', + }, + ], + }, + { + type: 'category', + label: 'SEP-24', + link: { + type: 'generated-index', + title: 'SEP-24', + slug: '/category/anchor-platform/rpc/sep-24', + }, + items: [ + { + type: 'doc', + id: 'anchor-platform/rpc/notify_interactive_flow_completed', + label: 'Interactive flow completed', + className: 'api-method patch', + }, + ], + }, + { + type: 'category', + label: 'SEP-31', + link: { + type: 'generated-index', + title: 'SEP-31', + slug: '/category/anchor-platform/resources/sep-31', + }, + items: [ + { + type: 'doc', + id: 'anchor-platform/rpc/notify_interactive_flow_completed', + label: 'Interactive flow completed', + className: 'api-method patch', + }, + ], + }, +]; diff --git a/i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/README.mdx b/i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/README.mdx new file mode 100644 index 000000000..4d3df22fc --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/README.mdx @@ -0,0 +1,11 @@ +--- +title: Stellar Disbursement Platform Introduction +sidebar_position: 10 +slug: /stellar-disbursement-platform +--- + +# Stellar Disbursement Platform + +The Stellar Disbursement Platform (SDP) is a tool built for organizations to make bulk payments to a group of recipients over the Stellar network. + +In this section, you'll find an [Admin Guide](./admin-guide/README.mdx) that will teach you how to run the Stellar Disbursement Platform as well as an [API Reference](./api-reference/resources/README.mdx). diff --git a/i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/admin-guide/README.mdx b/i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/admin-guide/README.mdx new file mode 100644 index 000000000..39975a6f9 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/admin-guide/README.mdx @@ -0,0 +1,11 @@ +--- +title: Admin Guide +sidebar_position: 15 +--- + +import DocCardList from "@theme/DocCardList"; + +All you need to know about setting up, running, and using the Stellar +Disbursement Platform. + + diff --git a/i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/admin-guide/anchor-platform-integration-points.mdx b/i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/admin-guide/anchor-platform-integration-points.mdx new file mode 100644 index 000000000..666700076 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/admin-guide/anchor-platform-integration-points.mdx @@ -0,0 +1,44 @@ +--- +title: Anchor Platform Integration Points +sidebar_position: 60 +--- + +As mentioned in the [Design and Architecture](./design-and-architecture.mdx) guide, the Stellar Disbursement Platform consists of a few services deployed together, where the Anchor Platform is one of them. + +For that reason, there are some connection points between the two instances that need to be properly configured in order for the Stellar Disbursement Platform to work correctly. We will be covering these integration points in this guide. + +Please note that for the default deployment of the Stellar Disbursement Platform, that relies on default Helm values and default Wallets and Assets, no extra configuration is needed. This guide is for those who want to customize the deployment by changing the Wallets and Assets available in their SDP instance. + +## Role of the Anchor Platform in SDP + +The Wallet Registration flow kicks off within the recipient's wallet app. This app interacts with the [Anchor Platform] to initiate the [SEP-24] deposit process through the SDP (Stellar Disbursement Platform). The SDP collects the necessary recipient information to ultimately execute the payment to them. + +The Anchor Platform (AP) is used to handle the implementation of interoperability protocols such as [SEP-1], [SEP-10], and [SEP-24], making their endpoints available to wallet apps. The [Anchor Platform] is pre-configured in both [the repo]'s Helm chart, and in the Docker Compose file available in the `dev` directory. + +## Steps for Configuring SDP-AnchorPlatform Integration + +To ensure a seamless integration between the SDP and the [Anchor Platform], make sure to follow these steps: + +1. 🚨 **Critical Step**: Configure the Anchor Platform with `PLATFORM_SERVER_AUTH_TYPE: JWT`. This setting is crucial for securing your Anchor Platform's backoffice API via JWT token authentication. +2. **Shared Secrets for API Authentication**: The `SECRET_PLATFORM_API_AUTH_SECRET` in the Anchor Platform should match `ANCHOR_PLATFORM_OUTGOING_JWT_SECRET` in the SDP. +3. **Shared Secrets for SEP-24**: The secrets `SECRET_SEP24_INTERACTIVE_URL_JWT_SECRET` and `SECRET_SEP24_MORE_INFO_URL_JWT_SECRET` in the Anchor Platform need to align with `SEP24_JWT_SECRET` in the SDP. +4. **SEP-10 Configuration**: The `SECRET_SEP10_SIGNING_SEED` in the Anchor Platform should be consistent with both the `SEP10_SIGNING_PRIVATE_KEY` and `SEP10_SIGNING_PUBLIC_KEY` in the SDP. + +By following these steps, you'll ensure a secure and efficient integration between your SDP and Anchor Platform systems. + +## Manual Synchronization of Custom Assets and Wallets + +Currently, some configurations within the Anchor Platform are static and loaded via environment variables. On the other hand, the SDP reads these same configurations from its database and allows an owner user to modify them. This dynamic pertains particularly to the lists of supported assets and wallets. + +While we are actively exploring ways to automate this synchronization process, manual adjustments to the Anchor Platform configuration are necessary whenever an asset or wallet is added or removed on the SDP. + +1. **(Required) Update Supported Assets**: Whenever you change the list of supported assets in the SDP, it's essential to update the Anchor Platform's `ASSETS_VALUE` configuration to reflect these changes. Refer to [the repo]'s Helm values or Docker Compose file(s) for examples. +2. **(Optional, but Recommended) Wallets and SEP-10 Domains**: If you employ the `SEP10_CLIENT_ATTRIBUTION_REQUIRED: true` setting in the Anchor Platform - a recommended best practice - you must also update the `SEP10_CLIENT_ATTRIBUTION_ALLOW_LIST` to include trusted wallet domains. This ensures that the Anchor Platform will process SEP-10 requests only from trusted wallets. + +By adhering to these guidelines, you can ensure a consistent and secure configuration between your SDP and Anchor Platform instances. + +[sep-1]: https://stellar.org/protocol/sep-1 +[sep-10]: https://stellar.org/protocol/sep-10 +[sep-24]: https://stellar.org/protocol/sep-24 +[anchor platform]: https://github.com/stellar/java-stellar-anchor-sdk +[the repo]: https://github.com/stellar/stellar-disbursement-platform-backend diff --git a/i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/admin-guide/configuring-sdp.mdx b/i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/admin-guide/configuring-sdp.mdx new file mode 100644 index 000000000..d4ae6cd54 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/admin-guide/configuring-sdp.mdx @@ -0,0 +1,211 @@ +--- +id: configuring-sdp +title: Configuring the SDP +description: Understand the configuration options available for the Stellar Disbursement Platform (SDP) +keywords: + - SDP + - configuration +sidebar_position: 45 +--- + +Stellar Disbursement Platform services can be configured using a set of configuration options that are passed to the command line or set as environment variables. +Depending on how you're using and deploying the SDP, these configurations can be set in a ConfigMap in Kubernetes, as environment variables in a Docker container, passed in as command line arguments, etc. + +In this section we will discuss the different configuration options available for the SDP. + +**Notes:** + +- Configurations that are tagged with πŸ”‘ are sensitive and should be stored securely. +- These configurations are valid for version 2.x of the SDP. +- All configurations can be passed in as either environment variables or CLI flags. For instance, the env var `BASE_URL` could be passed in through the `--base-url` flag. CLI flags take priority over env vars, even though env vars are more convenient. + +## SDP Core Service + +For the most up-to-date configuration, you can run the following command in the [stellar-disbursement-platform-backend git repository](https://github.com/stellar/stellar-disbursement-platform-backend): + + + +```bash +./stellar-disbursement-platform serve --help +``` + + + +### Operational Configuration + +Operational Configuration allows controlling metrics, logging, and other operational aspects of the SDP Core Service. + +- `PORT` - The port on which the SDP Core Service will listen for incoming HTTP requests. Default: 8000. +- `LOG_LEVEL` - Determines the verbosity level of logs. Options: "TRACE", "DEBUG", "INFO", "WARN", "ERROR", "FATAL", or "PANIC". Default: "TRACE". +- `METRICS_PORT` - The port on which the SDP Core Service will expose its metrics. Default: 8002. +- `METRICS_TYPE` - The type of metrics to expose. Options: "PROMETHEUS". Default: "PROMETHEUS". +- `CRASH_TRACKER_TYPE` - The crash tracker type to use. Options: "SENTRY", "DRY_RUN". Default: "DRY_RUN". +- `SENTRY_DSN` - πŸ”‘ The DSN (client key) of the Sentry project. If not provided, Sentry will not be used. +- `ENVIRONMENT` - The environment where the application is running. Example: "development", "staging", "production". Default: "development". +- `DATABASE_URL` - πŸ”‘ The connection string for the PostgreSQL database. Format is `postgres://username:password@host:port/database?sslmode=disable`. Default: "postgres://localhost:5432/sdp?sslmode=disable". + > behaviour of `base_url` and `sdp_ui_base_url` will change after https://stellarorg.atlassian.net/browse/SDP-1148 is done. +- `BASE_URL` - The SDP backend server's base URL. Default: "http://localhost:8000". +- `SDP_UI_BASE_URL` - The SDP UI/dashboard Base URL used to send the invitation link when a new user is created. + +### Messaging Configuration + +Messaging Configuration allows configuring the messaging service used to send messages to recipients and sdp dashboard users. The default configuration is set to "DRY_RUN" which means no messages will be sent and the messages will be logged to the console. This is recommended for testing purposes only. + +- `EMAIL_SENDER_TYPE`: The messenger type used to send invitations to new dashboard users. Options: "DRY_RUN", "AWS_EMAIL". Default: "DRY_RUN". +- `SMS_SENDER_TYPE`: The messenger type used to send SMS messages to recipients. Options: "DRY_RUN", "TWILIO_SMS", "AWS_SMS". Default: "DRY_RUN". + +#### AWS Configuration + +The following configurations are required when using AWS SES or SNS to send emails or SMS messages. + +- `AWS_ACCESS_KEY_ID` - πŸ”‘ The AWS access key ID. +- `AWS_REGION` - The AWS region where the SES service is available. +- `AWS_SECRET_ACCESS_KEY` - πŸ”‘ The AWS secret access key. +- `AWS_SES_SENDER_ID` - The email that AWS SES will use as the sender when sending emails. Required when `EMAIL_SENDER_TYPE` is set to "AWS_EMAIL". +- `AWS_SNS_SENDER_ID` - The sender ID to use when sending SMS messages using AWS SNS. Required when `SMS_SENDER_TYPE` is set to "AWS_SMS". + +#### Twilio Configuration + +The following configurations are required when `SMS_SENDER_TYPE` is set to "TWILIO_SMS". + +- `TWILIO_ACCOUNT_SID` - πŸ”‘ The Twilio account SID. +- `TWILIO_AUTH_TOKEN` - πŸ”‘ The Twilio auth token. +- `TWILIO_SERVICE_SID` - The Twilio service SID. + +General Messaging Configuration: + +- `MAX_INVITATION_SMS_RESEND_ATTEMPTS` - The maximum number of attempts to resend the SMS invitation to the Receiver Wallets. Default: 3. + +### Stellar Configuration + +Stellar Configuration allows configuring accounts, transactions, and other Stellar-related settings. + +- `NETWORK_PASSPHRASE` - The Stellar network passphrase. Default "Test SDF Network ; September 2015". +- `HORIZON_URL` - The URL of the Horizon server to use for submitting transactions. Default "https://horizon-testnet.stellar.org/". +- `SEP10_SIGNING_PUBLIC_KEY` - The public key of the Stellar account that signs the SEP-10 transactions. It's also used to sign URLs. +- `SEP10_SIGNING_PRIVATE_KEY` - πŸ”‘ The private key of the Stellar account that signs the SEP-10 transactions. It's also used to sign URLs. +- `MAX_BASE_FEE` - The max base fee for submitting a Stellar transaction. Default: 10000. + +The remaining configurations related to distribution accounts are detailed in the `Stellar accounts configuration` section of [1.x to 2.x Migration Guide](single-tenant-to-multi-tenant-migration#environment-variables). + +### Security Configuration + +Security Configuration allows configuring the security aspects of the SDP Core Service. + +- `CORS_ALLOWED_ORIGINS` - Specifies the domains allowed to make cross-origin requests. "_" means all domains are allowed. Domains can contain wildcards, e.g., "https://_.example.com". +- `SEP24_JWT_SECRET` - πŸ”‘ The secret used to sign the JWT token for SEP-24 transactions. This secret is used during the receiver wallet registration flow. + +#### Dashboard Authentication Configuration + +The following configurations are related to dashboard user authentication and authorization. + +- `RESET_TOKEN_EXPIRATION_HOURS` - The expiration time in hours of the Reset Password Token. Default: 24 (hours). +- `EC256_PUBLIC_KEY` - The EC256 Public Key used to validate the token signature. This EC key needs to be at least as strong as prime256v1 (P-256). +- `EC256_PRIVATE_KEY` - πŸ”‘ The EC256 Private Key used to sign the authentication token. This EC key needs to be at least as strong as prime256v1 (P-256). +- `DISABLE_MFA` - Disables Multi-Factor Authentication (MFA) for the SDP dashboard users. +- `DISABLE_RECAPTCHA` - Disables Google reCAPTCHA v2 for the SDP dashboard users. This flag doesn't affect the reCAPTCHA used during the SEP-24 flow. + +#### Recaptcha Configuration + +The following configurations are required when using Google reCAPTCHA v2 to protect the SDP Core Service from bots. ReCaptcha is used both for dashboard users and receivers of funds during the SEP-24 flow. + +- `RECAPTCHA_SITE_KEY` - The Google reCAPTCHA v2 - I'm not a robot site key. +- `RECAPTCHA_SITE_SECRET_KEY` - πŸ”‘ The reCAPTCHA site secret key used to validate reCAPTCHA responses. + +### Anchor Platform Configuration + +Anchor Platform Configuration allows configuring the anchor platform used by the SDP Core Service. + +- `ANCHOR_PLATFORM_BASE_PLATFORM_URL` - The base URL of the anchor platform. +- `ANCHOR_PLATFORM_BASE_SEP_URL` - The base URL of the anchor platform's SEP-24 implementation. +- `ANCHOR_PLATFORM_OUTGOING_JWT_SECRET` - πŸ”‘ The JWT secret used to create a JWT token used to send requests to the anchor platform. + +### Event Broker and Scheduled Jobs Configuration + +For asynchronous processing, the SDP Core Service gives user the choice to use either the Event Broker or Scheduled Jobs. + +The configurations for this section are detailed in the `Event Broker and Scheduler Configurations` of the [1.x to 2.x Migration Guide](single-tenant-to-multi-tenant-migration#environment-variables). + +### Multi-tenancy Configuration + +The configurations for this section are detailed in `General Environment Variables` of the [1.x to 2.x Migration Guide](single-tenant-to-multi-tenant-migration#environment-variables). + +## Transaction Submission Service (TSS) + +For the most up-to-date configuration, you can run the following command in the [stellar-disbursement-platform-backend git repository](https://github.com/stellar/stellar-disbursement-platform-backend): + + + +```bash +./stellar-disbursement-platform tss --help +``` + + + +### General Configuration + +- `QUEUE_POLLING_INTERVAL` - Polling interval (seconds) to query the database for pending transactions to process. Default: 6. + +### Operational Configuration + +Operational Configuration allows controlling metrics, logging, and other operational aspects of the Transaction Submission Servic (TSS) + +- `LOG_LEVEL` - Determines the verbosity level of logs. Options: "TRACE", "DEBUG", "INFO", "WARN", "ERROR", "FATAL", or "PANIC". Default: "TRACE". +- `TSS_METRICS_PORT` - The port on which the TSS will expose its metrics. Default: 9002. +- `TSS_METRICS_TYPE` - The type of metrics to expose. Options: "PROMETHEUS". Default: "PROMETHEUS". +- `CRASH_TRACKER_TYPE` - The crash tracker type to use. Options: "SENTRY", "DRY_RUN". Default: "DRY_RUN". +- `SENTRY_DSN` - πŸ”‘ The DSN (client key) of the Sentry project. If not provided, Sentry will not be used. +- `ENVIRONMENT` - The environment where the application is running. Example: "development", "staging", "production". Default: "development". +- `DATABASE_URL` - πŸ”‘ The connection string for the PostgreSQL database. Format is `postgres://username:password@host:port/database?sslmode=disable`. Default: "postgres://localhost:5432/sdp?sslmode=disable". + > behaviour of `base_url` will change after https://stellarorg.atlassian.net/browse/SDP-1148 is done. +- `BASE_URL` - The SDP backend server's base URL. Default: "http://localhost:8000". + +### Stellar Configuration + +Stellar Configuration allows configuring accounts, transactions, and other Stellar-related settings. + +- `NETWORK_PASSPHRASE` - The Stellar network passphrase. Default "Test SDF Network ; September 2015". +- `HORIZON_URL` - The URL of the Horizon server to use for submitting transactions. Default "https://horizon-testnet.stellar.org/". +- `MAX_BASE_FEE` - The max base fee for submitting a Stellar transaction. Default: 10000. + +#### Channel Accounts Configuration + +The following configurations are required for using channel accounts to submit transactions to the Stellar network. + +- `NUM_CHANNEL_ACCOUNTS` - Number of channel accounts to utilize for transaction submission. Default: 2. +- `CHANNEL_ACCOUNT_ENCRYPTION_PASSPHRASE` - πŸ”‘ A Stellar-compliant ed25519 private key used to encrypt/decrypt the channel accounts' private keys. When not set, it will default to the value of the 'DISTRIBUTION_SEED' option. + +#### Distribution Accounts Configuration + +The following configurations are related to the distribution accounts used to send funds to recipients. This configuration should match the configuration in the SDP Core Service. +For more details, refer to the `Stellar accounts configuration` section of [1.x to 2.x Migration Guide](single-tenant-to-multi-tenant-migration#environment-variables). + +- `DISTRIBUTION_SIGNER_TYPE` - The type of signer used to sign Stellar transactions for the tenants' distribution accounts. Options: "DISTRIBUTION_ACCOUNT_ENV", "DISTRIBUTION_ACCOUNT_DB". Default: "DISTRIBUTION_ACCOUNT_DB". +- `DISTRIBUTION_ACCOUNT_ENCRYPTION_PASSPHRASE` - πŸ”‘ A Stellar-compliant ed25519 private key used to encrypt/decrypt the in-memory distribution accounts' private keys. It's mandatory when the distribution-signer-type is set to "DISTRIBUTION_ACCOUNT_DB". +- `DISTRIBUTION_PUBLIC_KEY` - The public key of the HOST's Stellar distribution account, used to create channel accounts. +- `DISTRIBUTION_SEED` - πŸ”‘ The private key of the HOST's Stellar distribution account, used to create channel accounts. + +### Event Broker Configuration + +If an Event Broker is used for asynchronous processing, the TSS will need to be configured to use it. +For more details, refer to the `Event Broker and Scheduler Configurations` of the [1.x to 2.x Migration Guide](single-tenant-to-multi-tenant-migration#environment-variables). + +- `EVENT_BROKER_TYPE` - The type of event broker to use. Options: "KAFKA", "NONE". Default: "KAFKA". +- `BROKER_URLS` - List of Message Broker URLs comma-separated. +- `CONSUMER_GROUP_ID` - Message Broker Consumer Group ID. +- `KAFKA_SASL_USERNAME` - πŸ”‘ Kafka SASL Username. +- `KAFKA_SASL_PASSWORD` - πŸ”‘ Kafka SASL Password. +- `KAFKA_SECURITY_PROTOCOL` - Kafka Security Protocol. Options: PLAINTEXT, SASL_PLAINTEXT, SASL_SSL, SSL. +- `KAFKA_SSL_ACCESS_CERTIFICATE` - πŸ”‘ Kafka SSL Access Certificate in PEM format that matches with the Kafka Access Key. +- `KAFKA_SSL_ACCESS_KEY` - πŸ”‘ The Kafka Access Key (keystore) in PEM format. + +## Dashboard + +The SDP Dashboard is a web application that allows users to manage their accounts, view transaction history, and more. Environment variables can be set either on a global `window._env_` object or as `process.env` variables. All environment variables used in this repo are in `src/constants/envVariables.ts` file, including types. The default location of the `window._env_` object is `public/settings/env-config.js`. + +### General Configuration + +- `API_URL` - The base URL of the SDP Core Service. Default: "http://localhost:8000". +- `STELLAR_EXPERT_URL` - The base URL of the Stellar Expert explorer. Default: "https://stellar.expert/explorer/testnet". +- `HORIZON_URL` - The base URL of the Horizon server. Default: "https://horizon-testnet.stellar.org". +- `RECAPTCHA_SITE_KEY` - The Google reCAPTCHA v2 - I'm not a robot site key. This key needs to match the key used in the SDP Core Service. diff --git a/i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/admin-guide/deploy-the-sdp.mdx b/i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/admin-guide/deploy-the-sdp.mdx new file mode 100644 index 000000000..5bc995b06 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/admin-guide/deploy-the-sdp.mdx @@ -0,0 +1,57 @@ +--- +title: Deploy the SDP +sidebar_position: 40 +--- + +In this guide, you will learn to deploy the SDP on a Kubernetes cluster using publicly available Helm charts. + +This option is recommended for persistent deployments of production or staging instances of the SDP. If you want to deploy the SDP on a local machine for development purposes, see [Run the SDP Locally](./getting-started.mdx#run-the-sdp-locally). + +Please note that configuring deployment details like ingress, TLS, resource limits, and so on are out of scope for this guide. This guide assumes that you have a Kubernetes cluster with a Postgres database deployed in the same cluster and that you have the necessary permissions to deploy the SDP. It also assumes that you have the operational knowledge to manage the cluster and the database. + +## Prerequisites + +- Kubernetes 1.19+ +- Helm 3.2.0+ +- Postgres 14.0+ + +## Installing the Chart + +### Add the Helm repository + +Before you can install the chart, you need to add the Stellar Helm repository. + +```bash +helm repo add stellar https://helm.stellar.org/charts +helm repo update +``` + +### Customize the values + +The SDP Helm chart has a number of configurable values. You can customize these values by creating a values file and passing it to the `helm install` command. + +We provided a sample values file that you can use as a starting point. This file has the minimum set of configurations required to deploy an SDP instance. You can download the file from the [SDP GitHub repository](https://github.com/stellar/stellar-disbursement-platform-backend/blob/develop/helmchart/sdp/minimal-values.yaml) or by running the following command: + +```bash +curl -O https://raw.githubusercontent.com/stellar/stellar-disbursement-platform-backend/develop/helmchart/sdp/minimal-values.yaml +``` + +You can find the full list of configurable values in the [SDP GitHub repository](https://github.com/stellar/stellar-disbursement-platform-backend/blob/develop/helmchart/sdp/README.md#stellar-disbursement-platform-sdp-parameters). + +There is a more detailed explanation of how to configure the SDP in the [Configuring the SDP Guide](configuring-sdp). + +### Multi-tenant considerations + +When running the SDP in a multi-tenant configuration, you will need to acquire wildcard TLS certificates to facilitate tenant provisioning as the SDP relies on subdomains to differentiate between tenants. This will allow you to provision tenants without having to manually configure TLS certificates for each tenant. You can use a service like [Let's Encrypt](https://letsencrypt.org/) or [Namecheap](https://www.namecheap.com/security/ssl-certificates/) to acquire these certificates. + +For more information about multi-tenancy in the SDP, see the [Design and Architecture Guide](design-and-architecture#multi-tenancy). + +### Install the chart + +To install the chart with the release name `sdp` and the values file `myvalues.yaml`: + +```bash +helm install sdp -f myvalues.yaml stellar/stellar-disbursement-platform +``` + +Now you should have a running SDP instance. To learn how to use the SDP, see [Create your first disbursement](./getting-started.mdx#create-your-first-disbursement). diff --git a/i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/admin-guide/design-and-architecture.mdx b/i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/admin-guide/design-and-architecture.mdx new file mode 100644 index 000000000..e8ab820a4 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/admin-guide/design-and-architecture.mdx @@ -0,0 +1,65 @@ +--- +title: Design and Architecture +sidebar_position: 20 +--- + +The Stellar Disbursement Platform consists of four services deployed together: + +- **Dashboard**: the user interface administrators use to initiate and track the progress of disbursements +- **SDP Core Service**: the core backend service that performs several functions: + - **Dashboard API**: the API used by the front-end UI for all disbursement requests. The API is documented [here](../api-reference/resources/README.mdx) + - **Admin API**: the API used by the host organization to manage tenant provisioning and configuration. The API is documented [here](../api-reference/resources/admin/README.mdx) + - **Messaging Service**: a recurring process that sends text messages to users prompting them to download the wallet selected for a particular disbursement and verify their phone with an OTP + - **Wallet Registration UI**: a web application that collects and verifies the recipient’s OTP code and verification information via Stellar’s [SEP-24: Hosted Deposit and Withdrawal](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0024.md) protocol +- **Anchor Platform Service**: the API server that the wallet uses to authenticate and initiate the recipient’s registration process through the SEP-24 deposit flow +- **Transaction Submission Service**: the service that submits all payment transactions to the Stellar network. This service is designed to maximize payment throughput, handle queuing, and graceful resubmission/error handling + +## Dependencies {#dependencies} + +- **Container Orchestration**: the SDP is packaged as Docker containers and can be deployed to Kubernetes or AWS Fargate. SDF provides a Helm Chart for Kubernetes +- **Postgres**: the SDP uses a Postgres database server for all of its services +- **Apache Kafka**: the SDP optionally uses Kafka for streaming events between services. This is primarily used between SDP Core Service and Transaction Submission Service +- **Twilio or AWS SNS and SES**: the SDP’s messaging service uses SMS messages via Twilio or AWS SNS and administrative emails for organization account setup and recovery via AWS SES +- **Stellar Accounts**: + - Distribution Account: the SDP requires access to at least one funded Stellar account to make payments to the recipient + - SEP-10 Auth Account: the SDP requires a Stellar account for the mutual authentication protocol [SEP-10: Stellar Web Authentication](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0010.md) used to connect to wallet applications + +## Architecture Diagram + +![Architecture Diagram](/assets/SDP/SDP2.png) + +## Database & Schemas {#database} + +The SDP uses a Postgres database for all of its services. The database schema is managed by the SDP Core Service and is versioned in the codebase. +The database schema is designed to be tenant-aware, meaning that each tenant has its own set of tables and data. This allows the SDP to be multi-tenant and support multiple organizations using the same instance. + +There are 3 types of schemas in the database: + +- **Admin Schema**: contains tables for managing tenants. This schema is used by the Admin API to manage tenant configuration and provisioning. +- **TSS Schema**: contains tables for managing transactions. This schema is used by the Transaction Submission Service to manage the state of payment transactions. +- **Tenant Schemas**: each tenant has its own schema that contains tables for managing disbursements, recipients, and other tenant-specific data. These schemas are prefixed with `sdp_`. + +## Multi-tenancy {#multi-tenancy} + +The SDP can be deployed in a multi-tenant configuration, where multiple organizations share the same instance of the SDP. Each organization is referred to as a tenant and has its own set of data and configuration. A host organization can manage multiple tenants and manage their configuration through the Admin API. + +### Tenant Resolution {#tenant-resolution} + +The SDP uses a tenant resolution strategy to determine which tenant a request belongs to. Tenant resolution is only required for unauthenticated requests, as authenticated requests include the tenant information already in the JWT token. + +- **Header**: the `SDP-Tenant-Name` header is used to specify the tenant name in the request. When present, this header is used to attempt resolving the tenant. +- **Subdomain**: the SDP can use the subdomain of the request URL to resolve the tenant. For example, `tenant1.sdp.backend.test` would resolve to the tenant `tenant1`. + +Resolution priority goes as follows: JWT token (authenticated requests) > Header > Subdomain. + +#### Single Tenant Mode {#single-tenant-mode} + +When single tenant mode is enabled using the `SINGLE_TENANT_MODE` environment variable, all tenants will automatically resolve to the default tenant. A default tenant is set by calling the API [`POST /tenants/default-tenant`](../api-reference/resources/default-tenant). + +Default tenant is useful for development purposes or when the SDP is used by a single organization. This allows the organization to skip specifying the tenant in every request and simplifies the SDP setup operationally by removing the need of providing wildcard TLS certificates for multi-tenant configurations. + +#### Subdomain Resolution {#subdomain-resolution} + +When running the SDP in multi-tenant mode, the SDP uses the subdomain of the request URL to resolve the tenant. For example, `tenant1.sdp.backend.test` would resolve to the tenant `tenant1`. This allows the SDP to differentiate between tenants without requiring the tenant name to be specified in the request. + +The subdomain resolution is particularly important for the Wallet Registration process, as the SDP relies on subdomains to differentiate between tenants during the SEP-24 deposit flow. Home domains, which contain the tenant name as a subdomain, are used during the registration process by the SDP to identify the tenant and route the wallet-registration request to the correct tenant context. diff --git a/i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/admin-guide/getting-started.mdx b/i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/admin-guide/getting-started.mdx new file mode 100644 index 000000000..bf54d9f0d --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/admin-guide/getting-started.mdx @@ -0,0 +1,414 @@ +--- +title: Getting Started +sidebar_position: 30 +--- + +import { CodeExample } from "@site/src/components/CodeExample"; + +In this guide, you will learn to: + +- create and fund a host distribution account that may be used to fund tenant-level distribution accounts or directly for making payments +- set up an instance of the Stellar Disbursement Platform (SDP) locally +- provision a new tenant and create login credentials for users belonging to tenant +- set up a Stellar account to accept funds as a receiver +- make your first disbursement +- register your receiver account with the SDP +- check your account balance after receiving payment + +By the end of this guide, you'll have a clear understanding of the Stellar Disbursement Platform's functionality and a working local setup ready for development or testing. + +Note that while we'll be using USDC and the [Demo Wallet][demo-wallet] in this guide, other Stellar assets and wallets can be used in development or production. + +## Create and Fund a Host Distribution Account + +You'll need a minimum of two accounts when using the Stellar Disbursement Platform, a distribution and receiver account. We'll create the distribution account now and will create the receiver account while making our first disbursment. + +1. Go to the [Stellar Demo Wallet][demo-wallet] and select "Generate keypair for new account" +2. Select the "Create account" button next to the public key to fund your account with XLM +3. Select the "Select from preset assets" button, and select USDC +4. Finally, select "Add trustline" to enable payments of USDC + +Now that we have an account that can send & receive USDC, lets fund it with enough USDC for our first disbursement. You can fund your distribution account from any liquidity source of Stellar USDC but here's how do it through the Circle Sandbox and Stellar Laboratory. + +1. Create a [Circle Sandbox][circle-sandbox] account +2. Once you're at the dashboard, Select "Get API Key", and copy it to your clipboard +3. Go to the [Circle Sample App][circle-sample-app] and enter your API key after selecting the settings icon in the top right corner +4. Select "Charge Flow", then "Prefill Form", and select a card to use (it doesn't matter which) +5. Enter the amount you'd like to purchase, then select "Make Payment" + +This will fund your Circle Sandbox Account with USDC. You can repeat the process above when you run out or the test network resets, which happens quarterly. + +Your USDC should appear in your account within a few minutes, which you can check using the [balances endpoint](https://sample-sandbox.circle.com/debug/payments/balances/fetch). Once funded, you can send it to your distribution account created earlier. + +1. Select the icon in the top left, then "Payouts API", and finally "POST /transfers" +2. Select "Get Master Wallet ID" to load the wallet funded with USDC +3. Enter the amount you'd like to send +4. Select the "blockchain" destination type and then "XLM" +5. Paste the public key of the account you created with the demo wallet earlier +6. Select "Make API Call" + +Circle will submit payment of USDC to the Stellar test network and you should receive funds in your demo wallet account almost immediately! + +You can also acquire USDC through the [Stellar Laboratory](https://laboratory.stellar.org/#?network=test) if you prefer. Before starting, make sure your demo wallet account is funded with XLM and has a trustline to USDC. Build a transaction in the Laboratory with your demo wallet account as the source account. Create a Path Payment Strict Send operation with the same account as the destination account. Use XLM (native) as the sending asset and USDC issued by GBBD47IF6LWK7P7MDEVSCWR7DPUWV3NY3DTQEVFL4NAT4AQH3ZLLFLA5 as the destination asset. You can set your preferred minimum destination amount based on how much XLM you send but the amount isn't important in testnet. A very low minimum will ensure the trade. Sign the transaction and submit to the network. + +USDC will arrive in your demo wallet account within seconds! Refresh the account on the demo wallet page to see the new balance. + +## Run the SDP Locally + +### Prerequisites + +#### Docker + +Make sure you have Docker installed on your system. If not, you can download it from [here](https://docs.docker.com/get-docker/). + +#### Stellar Accounts + +We will need two Stellar accounts to set up the SDP, one of which you already created above. + +1. A Host Distribution account that will be used for sending funds to receivers. You should have just created this account using the [Create and Fund a Host Distribution Account](#create-and-fund-a-host-distribution-account) process above. +2. A SEP-10 account that will be used for authentication. It can be created the same way as the distribution account, but it doesn't need to be funded. Make sure to create this account now if you haven't already done so. + +The public and private key of these two accounts will be used to configure the SDP in the next step. + +### Run the SDP + +First you'll need to clone the project. + + + +```bash +git clone git@github.com:stellar/stellar-disbursement-platform-backend.git +``` + + + +Before we run the SDP, we need to configure it with the accounts created in the previous step. + + + +```bash +cd stellar-disbursement-platform-backend/dev +``` + + + +Create a `.env` file in the dev directory by copying the `.env.example` file: + + + +```bash +cp .env.example .env +``` + + + +Update the `.env` file with the public and private keys of the two accounts created in the previous step. + +Execute the following command to create all the necessary Docker containers needed to run SDP as well as provision sample tenants: + + + +```bash +./main.sh +``` + + + +This will bring up the following services: + +- `sdp_v2_database`: The main SDP and TSS database. +- `anchor-platform-postgres-db`: Database used by the anchor platform. +- `anchor-platform`: A local instance of the anchor platform. +- `sdp-api`: SDP service running on port 8000. +- `sdp-tss`: Transaction Submission service. +- `sdp-frontend`: SDP frontend service running on port 3000. +- `kafka`: Kafka service running on ports 9092, 9094(external). +- `kafka-init`: Initial workflow to exec into the Kafka container and create topics. +- `demo-wallet`: The demo wallet client that will be used as a receiver wallet, running on port 4000. + +> If you wish to start the sdp containers with monitoring services, you can use the docker-compose-monitoring.yml file +> +> `docker-compose -f docker-compose.yml -f docker-compose-monitoring.yml up` + +The following are optional monitoring services that can be started through docker-compose-monitoring.yml and are primarily used for monitoring Kafka: + +- `db-conduktor`: Database instance for the Conduktor service. +- `conduktor-monitoring`: Conduktor Monitoring service integrated into the Conduktor Platform. +- `conduktor-platform`: Provides solutions for Kafka management, testing, monitoring, data quality, security, and data governance. + +## New Tenant Provisioning Process + +When you ran `main.sh` file, you've already created new tenants: `tenants=("redcorp" "bluecorp")`. To add more tenants, simply append them separated by spaces to that variable like so: `tenants=("redcorp" "bluecorp" "greencorp")` and run main.sh again. + +Be sure that the added tenant hosts are included in the host configuration file. To check it, you can run the command cat `/etc/hosts`. To include them, you can run command sudo nano /etc/hosts and insert the lines below: + +``` +127.0.0.1 bluecorp.sdp.local +127.0.0.1 redcorp.sdp.local +``` + +## Setup Owner User Password for each tenant + +Go through the forgot password flow to be able to login as an owner user. + +Go to Forgot Password page on `http://${tenant}.stellar.local:3000/forgot-password` and enter the tenant and owner email `owner@${tenant}.org`. + +A token will be generated, and it's possible to check it on `sdp-api` logs. This token will be needed to Reset Password on `http://${tenant}.stellar.local:3000/reset-password`. + +## Create Your First Disbursement + +Navigate to the frontend service by opening a browser and going to http://bluecorp.stellar.local:3000. + +- Click `New Disbursement+` on the Dashboard screen. +- Use `Demo Wallet` as your wallet and choose a verification method. +- Upload a disbursement file. A sample file is available at `./dev/sample/sample-disbursement.csv`. Make sure to update the invalid phone number before using it. +- Finally, confirm the disbursement. + +## Log In + +Once the password for your target org user has been reset to one of your choice, navigate to the dashboard by opening a browser to localhost:3000 and login with the user account. +![Login](/assets/SDP/SDP26.png) + +Click the Sign in button and the SDP Dashboard will open. You will have no disbursements data at this point. +![Dashboard](/assets/SDP/SDP27.png) + +## Create Your First Disbursement + +Create your first disbursement by clicking the New Disbursement button. Use Demo Wallet as your wallet and USDC as your asset. You can choose whatever values you like for Country and Name, but ensure that Verification type matches the type used in the disbursement file that you will then upload with receiver information. Refer to `./dev/sample/sample-disbursement.csv` for the disbursement file template. +![Disbursement Details](/assets/SDP/SDP28.png) + +You also have the option of modifying the message in the receiver invite. +![Disbursment Details 2](/assets/SDP/SDP29.png) + +## Deposit Money + +To deposit money into your account: + +- Access [demo-wallet](http://localhost:4000) in your browser. +- Click on `Generate Keypair for new account` to generate a new keypair. Make sure to save your public key & secret if you want to use this account later. +- Click `Create account` (in front of public key) to actually create the account on the Stellar testnet. +- Your newly created account will have 10,000 XLM. +- Add your home domain to the account by clicking on `Add Home Domain` and entering `http://bluecorp.stellar.local:8000`. +- In the `Select action` dropdown, select `SEP-24 Deposit`. +- In the new window, enter the phone number from the disbursement CSV. +- Enter the passcode. You can use `000000` passcode or find the actual passcode in the `sdp-api` container logs. +- Enter the birthday that matches the phone number in the CSV. +- Keep an eye on the dashboard until the payment status reaches `Success`. If everything was set up correctly, your money should be disbursed successfully. + +## Troubleshooting + +### Distribution account out of funds + +Payments will start failing if the distribution account runs out of funds. To fix this, you can either write a script that funds the distribution account or use the tools available to add more funds to the distribution account by following these steps: + +- The distribution account address can be found under `Distribution Account` on the frontend sidebar. Depending on the value of `DISTRIBUTION_SIGNER_TYPE` that's configured in `dev/docker-compose.yml`, this account may either be the host account or a new account that was created during the tenant provisioning process. +- Access [https://horizon-testnet.stellar.org/accounts/:accountId](https://horizon-testnet.stellar.org/accounts/GARGKDIDH7WMKV5WWPK4BH4CKEQIZGWUCA4EUXCY5VICHTHLEBXVNVMW) in your browser and check the balance. +- If the balance is indeed low, you can add more funds by creating a new account and sending funds to the distribution account. + - Access in your browser. + - Click on `Generate Keypair for new account` to create a new testnet account. Your account comes with 10,000 XLM. + - Click on `Send` and enter the distribution account public key and the amount you want to send. + - Using Freighter or [Stellar Laboratory](https://laboratory.stellar.org/#account-creator?network=test), swap the XLM for USDC if you wish to test with USDC. + +## Verify Your Identity + +When a disbursement is created, the SDP attempts to send SMS messages to receivers using either Twilio or AWS SNS. This message includes a link to the wallet application selected when creating the disbursement, and should direct the receiver to install the wallet app, go through the wallet's onboarding flow, and finally register with the SDP. However, neither service is configured by default, so the SDP will not send an SMS message to the phone numbers listed in the CSV uploaded in the previous step. You can still see the message in the `sdp-api` container logs. + +Check out the [Email and SMS Messages](#email-and-sms-messages) section to learn how to configure messaging in the SDP. When you do, and another disbursement is created, you should get a message like the following. + +![Verify Identity](/assets/SDP/SDP8.png) + +## Create a Receiver Account + +Clicking on the link within the SMS message will bring you back to the Stellar Demo Wallet, where you'll need to create another account to receive the USDC. Follow the same process described earlier to create the account and add a USDC trustline. + +## Initiate SEP-24 Webflow + +Now we'll need to connect the demo wallet to the SDP instance running locally. To do that, select the pencil icon next to "centre.io" below your USDC balance and enter "localhost:8080". + +In the "Select Action" dropdown, select "SEP-24 Deposit" to initiate a SEP-24 webflow, which triggers the User Registration process to link the new wallet to the phone number in the SDP. + +![SEP-24](/assets/SDP/SDP13.png) + +A SEP-24 interactive window will appear. This simulates the wallet application popup you would see on your mobile phone. Enter the phone number from the disbursement CSV. + +![Webflow](/assets/SDP/SDP14.png) + +Next, enter the passcode and the verification field that you used in the disbursement file. Note: use 000000 for this example (or 999999 if you want to see an error response). + +![Passcode and Birthday](/assets/SDP/SDP15.png) + +The webflow provides a message indicating your successful registration, which is the trigger for the SDP to send the payment. You should receive your payment from the SDP shortly. + +![Message](/assets/SDP/SDP16.png) + +## Check Your Balance + +Refresh your account. The Demo Wallet should now show a balance of 2 USDC sent from the SDP (or however much was defined in the CSV file). + +![Success](/assets/SDP/SDP17.png) + +Keep an eye on the dashboard until the payment status reaches Success. If everything was set up correctly, your money should be disbursed successfully. + +![Disbursement](/assets/SDP/SDP18.png) + +## Next Up: Updating Application Secrets + +Now that you've been able to make a disbursement, let's go back to our docker compose files and update some values. **This is an important step before going to production. We'll be updating encryption keys and application secrets.** + +### Email and SMS Messages + +The Stellar Disbursement Platform sends SMS messages and emails to receivers and users, respectively. For SMS messages, the Stellar Disbursement Platform supports Twilio, AWS SNS, and a dry run mode that just logs the messages. For emails, it supports AWS SES and dry run. + +These services can be selected through the `SMS_SENDER_TYPE` and `EMAIL_SENDER_TYPE` configurations. When selecting Twilio or AWS services, you'll need to fill their service-specific configuration as well. Here are some example configurations. You can mix and match the services as you see fit. + +#### Dry Run Configuration + +Dry run mode is useful for testing the SDP without sending real messages. It will log the messages to the console instead of sending them to the receiver. This is the default configuration and it works for both SMS and Email. + + + +```yaml +EMAIL_SENDER_TYPE: DRY_RUN +SMS_SENDER_TYPE: DRY_RUN +``` + + + +#### Twilio SMS Configuration + + + +```yaml +SMS_SENDER_TYPE: TWILIO_SMS + +# Twilio specific configuration +TWILIO_ACCOUNT_SID: +TWILIO_AUTH_TOKEN: +TWILIO_SERVICE_SID: +``` + + + +#### AWS SMS Configuration + + + +```yaml +SMS_SENDER_TYPE: AWS_SMS + +# AWS specific configuration. +# This is needed for both AWS Email and SMS +AWS_ACCESS_KEY_ID: +AWS_REGION: +AWS_SECRET_ACCESS_KEY: + +# AWS SNS configuration +AWS_SNS_SENDER_ID: +``` + + + +#### AWS Email Configuration + + + +```yaml +EMAIL_SENDER_TYPE: AWS_EMAIL + +# AWS specific configuration. +# This is needed for both AWS Email and SMS +AWS_ACCESS_KEY_ID: +AWS_REGION: +AWS_SECRET_ACCESS_KEY: + +# AWS SNS configuration +AWS_SES_SENDER_ID: +``` + + + +### Authentication + +Wallets authenticate with the Stellar Disbursement Platform using a mutual authentication protocol, where both the SDP and wallet prove they are in possession of their Stellar accounts by signing a payload exchanged between themselves. Once this process is complete, a JWT is provided to the wallet to use in future requests. Additionally, the SDP's microservices uses authentication tokens to communicate between themselves, and to encrypt user passwords. We need to provide updated values for all these use cases. + +In `docker-compose-sdp-anchor.yml`, update the following: + + + +```yaml +# The public key of the Stellar account used for SEP-10 authentication: +SEP10_SIGNING_PUBLIC_KEY: +# +# The private key of the Stellar account used for SEP-10 authentication. It +# should be the same secret key for both attributes below, for the Stellar +# Disbursement Platform and Anchor Platform: +SEP10_SIGNING_PRIVATE_KEY: +SECRET_SEP10_SIGNING_SEED: +# +# The encryption key used to sign the resulting SEP-10 JWT token: +SECRET_SEP10_JWT_SECRET: +# +# A shared encryption key used to sign JWT tokens in the SEP-24 from the Anchor +# Platform to the Stellar Disbursement Platform. The value needs to be the same +# for all three attributes below: +SEP24_JWT_SECRET: +SECRET_SEP24_INTERACTIVE_URL_JWT_SECRET: +SECRET_SEP24_MORE_INFO_URL_JWT_SECRET: +# +# A shared encryption key used to sign JWT tokens in the PlatformAPI +# communications from the Stellar Disbursement Platform to the Anchor Platform. +# The value needs to be the same for both attributes below: +ANCHOR_PLATFORM_OUTGOING_JWT_SECRET: +SECRET_PLATFORM_API_AUTH_SECRET: +# +# The private key is used to sign JWT tokens for authenticating the requests +# incoming to the Stellar Disbursement Platform. The Public key is used to +# validate that the JWT token was signed by the SDP's private key. They can be +# generated with these commands: +# openssl ecparam -name prime256v1 -genkey -noout -out ec_private_key.pem +# openssl pkcs8 -topk8 -nocrypt -in ec_private_key.pem -out ec_private_key_pkcs8.pem +# openssl ec -in ec_private_key.pem -pubout -out ec_public_key.pem +EC256_PUBLIC_KEY: +EC256_PRIVATE_KEY: +# +``` + + + +There are many other configuration values to update when moving to a production environment, such as database credentials, URLs, and more. + +## Level Up: Customize Default Options + +The SDP contains a list of assets, countries, and wallets available for disbursements out-of-the-box. You might want to customize these, either to limit/expand options or to prepare for going live in production. Now that you've made a disbursement and added application secrets, let's look at how to customize the new disbursement options. + +### Assets + +You can add and remove assets easily in the SDP dashboard. The SDP backend handles the request seamlessly, including checking for outstanding balance and adding/removing trustlines on the Stellar network. When assets are removed, the record is still retained in the database to preserve a full history. However, the asset will no longer be available for disbursements or holding a balance in the distribution account. + +Head to the Wallets page of the SDP dashboard to add and remove assets. You'll need the Stellar asset code and the public key of the asset issuer. + +> Note: please make sure to update the appropriate configuration on the Anchor Platform side, according with the [Anchor Platform Integration Points](./anchor-platform-integration-points.mdx#manual-synchronization-of-custom-assets-and-wallets) guide. + +### Countries + +To customize wallets and countries, you’ll need to do some backend work. + +The list of available countries is seeded with a database patch. The default list includes every country except North Korea, Iran, Cuba, and Syria for easy testing. If you want to narrow the list, you will need to remove the country record directly from the countries table within the SDP database. + +Here is an example of how to remove France with its three-character ISO 3166 code: + + + +```sql +DELETE FROM countries WHERE code = 'FRA'; +``` + + + +### Wallets + +For a full overview on how to add wallets and how to make a wallet SDP-compatible, check out the [Making Your Wallet SDP-Ready](./making-your-wallet-sdp-ready.mdx) guide. + +[demo-wallet]: https://demo-wallet.stellar.org +[circle-sandbox]: https://login-sandbox.circle.com/ +[circle-sample-app]: https://sample-sandbox.circle.com/ diff --git a/i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/admin-guide/making-your-wallet-sdp-ready.mdx b/i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/admin-guide/making-your-wallet-sdp-ready.mdx new file mode 100644 index 000000000..0f26c8f73 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/admin-guide/making-your-wallet-sdp-ready.mdx @@ -0,0 +1,176 @@ +--- +title: Making Your Wallet SDP-Ready +sidebar_position: 50 +--- + +import { CodeExample } from "@site/src/components/CodeExample"; + +Remember that any SDP instance will need an agreement with a wallet provider before sending disbursements into that wallet. This ensures the wallets are comfortable receiving funds from your organization and governs any commercial arrangement between the organizations. The wallet will need to allowlist the SDP domain before the SDP can send disbursements to that wallet. When the wallet domain is added to a SDP, it's effectively being allowlisted by the SDP. Both sides listing the other allows them to retrieve the stellar.toml file and check the signing key needed for the [SEP-10] handshake. + +In this page, we will cover the technical aspects of the SDP-Wallet integration, including how to add a Wallet in the SDP database, how to validate and support the registration links using mobile app's [deep linking], how to start the user registration flow in the wallet using [SEP-24], and a recommended approach for handling [deferred deep linking]. + +## Adding a Wallet to an SDP + +The default list of SDP wallets depends on which network is being used (testnet or pubnet). The network is passed as an environment variable and then the list of wallets can be seeded appropriately on SDP startup through the CLI command `./stellar-disbursement-platform db setup-for-network`, according with a hardcoded list of known wallets. Alternatively, wallets can be inserted directly into the SDP database through a SQL command. Both methods require adding the wallet name, homepage, SEP-10 client domain, and deep link schema. + +To insert it directly into the database, update your values and run the following Postgres query. Make sure to check your database and namespace first. + + + +```sql +INSERT INTO wallets (name, homepage, deep_link_schema, sep_10_client_domain) +VALUES ('Vibrant Assist', 'https://vibrantapp.com', 'https://vibrantapp.com/sdp', 'api.vibrantapp.com'); +``` + + + +To configure a wallet through the code, add it to the testnet or pubnet section of `DefaultWalletsNetworkMap`. This will be used when you execute the `./stellar-disbursement-platform db setup-for-network` CLI command, which updates the SDP database and makes the wallet available for new disbursements. Add your new wallet following the same format already present in the code. + + + +```go +var DefaultWalletsNetworkMap = WalletsNetworkMapType{ + utils.PubnetNetworkType: { + { + Name: "Vibrant Assist", + Homepage: "https://vibrantapp.com/assist", + DeepLinkSchema: "https://vibrantapp.com/sdp", + SEP10ClientDomain: "api.vibrantapp.com", + }, + }, + utils.TestnetNetworkType: { + { + Name: "Vibrant Assist", + Homepage: "https://vibrantapp.com", + DeepLinkSchema: "https://vibrantapp.com/sdp-dev", + SEP10ClientDomain: "api-dev.vibrantapp.com", + }, + { + Name: "Demo Wallet", + Homepage: "https://demo-wallet.stellar.org", + DeepLinkSchema: "https://demo-wallet.stellar.org", + SEP10ClientDomain: "demo-wallet-server.stellar.org", + }, + }, +} +``` + + + +> Note: please make sure to update the appropriate configuration on the Anchor Platform side, according with the [Anchor Platform Integration Points](./anchor-platform-integration-points.mdx#manual-synchronization-of-custom-assets-and-wallets) guide. + +## Recipient Registration Experience + +The recipient registration experience is paramount to make this application smooth and easy to use. this requires the wallet to support [deferred deep linking], which will be discussed in a later section. A good description of the registration experience is as follows: + +1. The recipient receives an SMS message notifying them they have a payment waiting from the organization and prompts them to click a [deep link] to open or install&open a wallet application + +2. When the recipient opens the wallet app, the wallet immediately onboards the recipient, creates a Stellar account and trustline for the desired asset, initiates a [SEP-24] deposit transaction with the SDP, and opens the SDP's registration webpage as an overlay screen/iframe inside the app. + +3. The user confirms their phone number and date of birth directly with the SDP, without sharing any data with the wallet, and after the registration finishes, the user is sent back to the wallet application. Here are the screens demonstrating these steps: + + ![Registration Flow](/assets/SDP/SDP25.png) + +4. The user receives the payment within seconds + +## Registration Deep Link + +Once the user has installed the wallet application, the wallet should be able to interpret a [deep link] that follows the format registered in the SDP in order to kick off the [Wallet Registration Procedure](#wallet-registration-procedure). The deep link format supported by the SDP follows this format: + +```url +https://?asset=&domain=&name=&signature= +``` + +- `asset`: the Stellar asset. +- `domain`: the domain hosting the SDP's `stellar.toml` file. The wallet will need to use it to both fetch the `stellar.toml` file, and to populate the `home_domain` field in the [SEP-10] GET challenge transaction. +- `name`: the name of the organization sending payments. +- `signature`: a signature from the SDP's [SEP-10] signing key. + +> Note that the deep link is specific to each SDP, payer org, and asset. It is not specific per individual receiver. There is no risk in sharing the link with receivers who are part of the same disbursement. The link will be the same for multiple receivers and they will prove their identity as part of the [SEP-24] deposit flow. + +Below is an example of a registration link (signed) + +```url +https://vibrantapp.com/sdp-dev?asset=USDC-GBBD47IF6LWK7P7MDEVSCWR7DPUWV3NY3DTQEVFL4NAT4AQH3ZLLFLA5&domain=ap-stellar-disbursement-platform-backend-dev.stellar.org&name=Stellar+Test&signature=fea6c5e805a29b903835bea2f6c60069113effdf1c5cb448d4948573c65557b1d667bcd176c24a94ed9d54a1829317c74f39319076511512a3e697b4b746ae0a +``` + +In this example, the host is `https://vibrantapp.com/sdp-dev` and the signature is the result of signing the below (unsigned) url using the [SEP-10] signing key `SBUSPEKAZKLZSWHRSJ2HWDZUK6I3IVDUWA7JJZSGBLZ2WZIUJI7FPNB5`, with the public key being `GBFDUUZ5ZYC6RAPOQLM7IYXLFHYTMCYXBGM7NIC4EE2MWOSGIYCOSN5F`: + +```url +https://vibrantapp.com/sdp-dev?asset=USDC-GBBD47IF6LWK7P7MDEVSCWR7DPUWV3NY3DTQEVFL4NAT4AQH3ZLLFLA5&domain=ap-stellar-disbursement-platform-backend-dev.stellar.org&name=Stellar+Test +``` + +In this example, the signature is `fea6c5e805a29b903835bea2f6c60069113effdf1c5cb448d4948573c65557b1d667bcd176c24a94ed9d54a1829317c74f39319076511512a3e697b4b746ae0a`. + +Below is a JavaScript snippet demonstrating how to verify the signature: + +```js +#!/usr/bin/env node + +const { Keypair } = require("stellar-sdk"); + +// The SDP's stellar.toml SIGNING_KEY +// +// For security, this should ideally be fetched from +// https:///.well-known/stellar.toml on demand +const keypair = Keypair.fromPublicKey( + "GBFDUUZ5ZYC6RAPOQLM7IYXLFHYTMCYXBGM7NIC4EE2MWOSGIYCOSN5F", +); +console.log("public key:", keypair.publicKey()); + +let url = + "https://vibrantapp.com/sdp-dev?asset=USDC-GBBD47IF6LWK7P7MDEVSCWR7DPUWV3NY3DTQEVFL4NAT4AQH3ZLLFLA5&domain=ap-stellar-disbursement-platform-backend-dev.stellar.org&name=Stellar%20Test"; +let signature = + "fea6c5e805a29b903835bea2f6c60069113effdf1c5cb448d4948573c65557b1d667bcd176c24a94ed9d54a1829317c74f39319076511512a3e697b4b746ae0a"; + +console.log( + "verified:", + keypair.verify( + Buffer.from(url.toString(), "utf8"), + Buffer.from(signature, "hex"), + ), +); +``` + +### Wallet Registration Procedure + +When opening registration [deep link], these are the steps the wallet should follow in order to enforce the security and privacy measures expected in this flow, and to allow the user to input their information directly with the SDP: + +1. 🚨 Confirm that the `domain` of the deep link is on the wallet's allowlist. This is crucial for authenticating from a trusted wallet.🚨 +2. Fetch the SDP's toml file at `{domain}/.well-known/stellar.toml` and confirm the `SIGNING_KEY` variable is populated. +3. Verify that the registration link signature was made using `SIGNING_KEY` similar to the `keypairPk.verify(...)` function in the snippet above, and that the signature is valid with the content of the link. +4. Check the `asset` from the link and confirm that the recipient user has a trustline for that asset. Create one if it doesn't exist. +5. (Optional) Use the `name` from the link to update the wallet user interface. +6. Initiate the [SEP-24] deposit flow with that asset using the `TRANSFER_SERVER_SEP0024` value from the SDP's toml file. + - This includes using [SEP-10] to authenticate the user with the SDP server. Please notice that the SDP requires both the `client_domain` and `home_domain` fields to be provided in the `GET ` request, and they should be set as follows: + - `client_domain`: the domain of the wallet server that exposes the wallet server's `stellar.toml` file. + - `home_domain`: the domain of the SDP's server that was present in the registration link. + - `account`: the Stellar account of the receiver's wallet. +7. Launch the deposit flow interactive _in-app browser_ within your mobile app, following the instructions in the [SEP-24] spec. + - ATTENTION: the wallet should not, in any circumstances, scrape or attempt to scrape the content from the _in-app browser_ for the recipient's information. + - NOTE: it's highly recommended to use an _in-app browser_ rather than a webview. +8. πŸŽ‰ Congratulations! The recipient user can now fill out the forms in the _in-app browser_ and register to receive their payment πŸŽ‰. + +Additionally, the wallet should save the link and/or link attributes and associate it with the individual receiving user for these reasons: + +1. This is how the wallet will know that the user is associated with a certain org or SDP. +2. Saving the data is useful for reporting and troubleshooting, especially if the wallet needs to justify the source of funds for regulatory or tax purposes. +3. If the payer org wants to pay any cashout fees charged by the wallet or offramp, the wallet will need to know which users and transactions should be invoiced upstream. + +### Deferred Deep Links + +Most likely, the intended recipient will not have the necessary wallet application installed on their device. For this reason, wallets should support the concept of [deferred deep linking], which enables the following flow: + +1. The recipient's initial action of clicking the deep link should redirect them to the appropriate app store to download the wallet application. +2. After installing and opening the application, the recipient should be rerouted to the wallet's typical onboarding flow. +3. Once the user has successfully onboarded, the wallet should use the information included in the deep link to kick off the [Wallet Registration Procedure](#wallet-registration-procedure). + +Deferred deep linking is a feature commonly supported by numerous mobile deep linking solutions, there are third-party services that can be used to implement this functionality, such as Singular, Branch, AppsFlyer, Adjust, and others. [Here](https://medium.com/bumble-tech/universal-links-for-android-and-ios-1ddb1e70cab0) is a blog post with more information on how to implement [deferred deep linking]. + +The SDP supports a basic link format, such as `https://`. If your wallet's deep linking system needs a more complex structure, you'll have to manage this with a web application. This application should be owned by the wallet provider, and it should be able to receive the deep link, interpret it, and direct the user to the correct location. + +[deferred deep linking]: https://en.wikipedia.org/wiki/Mobile_deep_linking#Deferred_deep_linking +[deep link]: https://en.wikipedia.org/wiki/Mobile_deep_linking +[deep linking]: https://en.wikipedia.org/wiki/Mobile_deep_linking +[sep-10]: https://stellar.org/protocol/sep-10 +[sep-24]: https://stellar.org/protocol/sep-24 diff --git a/i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/admin-guide/migrating-to-sdp-multi-tenant.mdx b/i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/admin-guide/migrating-to-sdp-multi-tenant.mdx new file mode 100644 index 000000000..b05435ec0 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/admin-guide/migrating-to-sdp-multi-tenant.mdx @@ -0,0 +1,478 @@ +--- +id: single-tenant-to-multi-tenant-migration +title: 1.x to 2.x Migration Guide +description: Single-tenant to multi-tenant migration guide. +keywords: + - migration + - single-tenant + - multi-tenant + - SDP + - 1.x + - 2.x +--- + +import { CodeExample } from "@site/src/components/CodeExample"; + +Here you will find the required steps to migrate an existing single-tenant (`1.x`) Stellar Disbursement Platform application (SDP) to a multi-tenant (`2.x+`) version. + +## Why Migrate? + +Starting with version `2.x`, the SDP provides a multi-tenant architecture, where multiple organizations can manage disbursements under a unified infrastructure while maintaining separate datasets and funds management. + +New features and fixes will only be published to the multi-tenant version. + +The multi-tenant version also suits single-tenant scenarios, through a simplified configuration that will be described later in this document. + +> **DISCLAIMER**: this guide was prepared and tested with `1.1.6 -> 2.0.0-rc1` code bases. If you're in a later version, it's possible that the new database migrations cause an error when following these steps. +> +> You have the option of using the `2.0.0-rc1` version to perform this migration, and then upgrade to the latest version after the migration is completed. + +## Preparing for the Migrations + +### Halt the Single-Tenant Version 🚧 + +Before proceeding with the migration, ensure that the single-tenant version of the SDP is not running. This is crucial to prevent any data inconsistencies or conflicts during the migration process. + +### Double-Spending Prevention 🚨 + +To avoid double-spending, ensure that no payment is in the `PENDING` state, otherwise this could result in having the same payment submitted independently by both single-tenant and multi-tenant instances. You can do that by checking the `payments` table for any payment in the `PENDING` state: + + + +```sql +SELECT * FROM public.payments WHERE status = ANY(array['PENDING']::payment_status[]); +``` + + + +Similarly, check the `submitter_transactions` table for any transaction in the `PENDING` state: + + + +```sql +SELECT * FROM public.submitter_transactions WHERE status = ANY(array['PROCESSING']::transaction_status[]); +``` + + + +If there are any payments in the `PENDING` state or transactions in the `PROCESSING` state, you should wait for them to be processed and transitioned to either `SUCCESS` or `FAILED` before proceeding with the migration. + +### Remove Channel Accounts 🧹 + +In version `2.x`, the channel accounts are encrypted using the `CHANNEL_ACCOUNT_ENCRYPTION_PASSPHRASE`, which is a different env from the one used in the single-tenant version (`DISTRIBUTION_SEED`). To avoid any issues, let's remove all existing channel accounts in the single-tenant version priot to the migration: + + + +```bash +./stellar-disbursement-platform channel-accounts delete --delete-all-accounts +``` + + + +### Database Backup & Setup πŸ’Ύ + +Backup your single-tenant database before proceeding with the migration. At this point, the single-tenant instance should be halted, and there shouldn't be any `PENDING` payments nor `PROCESSING` submitter_transactions. + +It's also recommended that you create a new database for the multi-tenant version to avoid any data loss. Use the dump from the single-tenant database to populate the initial state of this multi-tenant one. From this point onwards, anytime we refer to **the database**, we'll be referring to the new multi-tenant database that was created from a dump of the single-tenant database. + +Here's how you can do the backup and restore: + + + +```bash +pg_dump --dbname=$singleTenantDB > sdp-singleTenant.sql +createdb $multiTenantDB +psql --dbname=$multiTenantDB < sdp-singleTenant.sql +``` + + + +## Changes Explained + +Among the changes introduced in the multi-tenant version, the most significant ones are: + +1. **Infrastructure**: the multi-tenant version includes an event-broker (Kafka) as an additional infrastructure component that is highly-recommended for multi-tenant setups, especially when high throughput is required. +2. **Environment Variables**: the multi-tenant version introduces new environment variables to configure the event broker, as well as additional variables relevant for multi-tenancy. +3. **Seggregation of Funds**: the multi-tenant version introduces the concept of a distribution account for each tenant, which is used to submit transactions on behalf of the tenant. There's also the HOST distribution account, that's used to fund the tenant distribution accounts and the TSS channel accounts. +4. **CLI Commands**: some CLI commands have been revised to be tenant-aware, while others have been included to support new multi-tenant features. +5. **Database Structure**: the database structure has been revised to accommodate multi-tenancy and the tables are now distributed across multiple schemas, providing isolation between tenants. + +### Infrastructure + +For the infrastructure setup, SDP Multi-tenant offers flexible operational modes. + +#### Event Broker vs Scheduled Jobs + +Administrators can choose between using an event broker for event-driven operations, or scheduled jobs for periodic operations. Event brokers are recommended for multi-tenant setups, as they provide a scalable and reliable way to handle events, while scheduled jobs are recommended for local setups or single-tenant SDPs. Also, event-brokers provide faster communication between services. + +#### Anchor Platform Version + +While the single-tenant used [`stellar/anchor-platform:2.1.3`](https://hub.docker.com/layers/stellar/anchor-platform/2.1.3/images/sha256-e6ef4b17a8d3e5d1455fa3d8f5f7e2a2b9534ad749584ff5446d685eb07837e9?context=explore), the multi-tenant version requires [`stellar/anchor-platform:2.6.0`](https://hub.docker.com/layers/stellar/anchor-platform/2.6.0/images/sha256-913fa2461d36d5150724a172ca46f8c76284a3890b60a9d5709fe0c606af78b9) or later. + +### Environment Variables + +Below are the environment variables that have been added or modified in the multi-tenant version. + +General environment variables: + +- `ADMIN_ACCOUNT`: The username of the admin account used to authenticate HTTP requests to the Admin server. The Admin-targeted requests should add the "Authorization" header, formatted as Base64-encoded `"ADMIN_ACCOUNT:ADMIN_API_KEY"`. +- `ADMIN_API_KEY`: The api key of the admin accountused to authenticate HTTP requests to the Admin server. The Admin-targeted requests should add the "Authorization" header, formatted as Base64-encoded `"ADMIN_ACCOUNT:ADMIN_API_KEY"`. +- `ADMIN_PORT`: the port of the Admin server used to create and manage tenants. Default is 8003. +- `INSTANCE_NAME`: the name of the SDP instance to be displayed in the `stellar.toml` file. Example: "SDP Testnet". +- `SINGLE_TENANT_MODE`: When set to `"true"`, it enables the single-tenant mode, which is useful for local development or single-tenant setups. In addition to set it to true, you'll need to configure the default tenant by calling the [`POST /tenants/default-tenant`](../api-reference/resources/default-tenant) request. +- `TENANT_XLM_BOOTSTRAP_AMOUNT`: The amount of XLM that the HOST Stellar account will deposit deposited to the tenant distribution account for tenant bootstrap. + +Stellar accounts configuration environment variables: + +- `CHANNEL_ACCOUNT_ENCRYPTION_PASSPHRASE`: A Stellar-compliant ed25519 private key used to encrypt/decrypt the channel accounts' private keys. When not set, it will default to the value of the 'distribution-seed' option, which was used in the single-tenant version. **Attention**, when migrating from the single-tenant, setting this config to something different from the old `DISTRIBUTION_SEED` will prevent the code from being able to decrypt the channel accounts. +- `DISTRIBUTION_SIGNER_TYPE`: The type of signer used to sign Stellar transactions for the tenants' distribution accounts. Options: `DISTRIBUTION_ACCOUNT_DB` (recommended), `DISTRIBUTION_ACCOUNT_ENV` (same as the single-tenant version). +- `DISTRIBUTION_ACCOUNT_ENCRYPTION_PASSPHRASE`: A Stellar-compliant ed25519 private key used to encrypt/decrypt the in-memory distribution accounts' private keys. It's mandatory when the distribution-signer-type is set to `DISTRIBUTION_ACCOUNT_DB`. + +Event broker configuration environment variables: + +- `BROKER_URLS`: A comma-separated list of the message broker URLs. +- `CONSUMER_GROUP_ID`: Specifies a group ID for the broker consumers. +- `EVENT_BROKER_TYPE`: Specifies the type of event broker to be used. Options: "KAFKA", "NONE". Defaults to "Kafka". +- `KAFKA_SECURITY_PROTOCOL`: Defines the security protocol for Kafka. Options: PLAINTEXT, SASL_PLAINTEXT, SASL_SSL, SSL. +- `KAFKA_SASL_USERNAME`: Specifies the Kafka SASL Username, required when the kafka security protocol is set to either `SASL_PLAINTEXT` or `SASL_SSL`. +- `KAFKA_SASL_PASSWORD`: Specifies the Kafka SASL Password, required when the kafka security protocol is set to either `SASL_PLAINTEXT` or `SASL_SSL`. +- `KAFKA_SSL_ACCESS_KEY`: The Kafka Access Key (keystore) in PEM format, required when the kafka security protocol is set to `SSL`. +- `KAFKA_SSL_ACCESS_CERTIFICATE`: The Kafka SSL Access Certificate in PEM format that matches with the Kafka Access Key, required when the kafka security protocol is set to `SSL`. + +Scheduler environment variables: + +- `ENABLE_SCHEDULER`: Default "false". This enables scheduled jobs that replace the operations of a broker for synchronizing payments between SDP and TSS as well as submitting receiver invitations. It should be set to "true" when the event broker is disabled. +- `SCHEDULER_PAYMENT_JOB_SECONDS`: Interval in seconds for the job that synchronizes payments between SDP and TSS. Minimum is 5s. +- `SCHEDULER_RECEIVER_INVITATION_JOB_SECONDS`: Interval in seconds for the job that submits receiver invitations. Minimum is 5s. + +On the Anchor Platform side, we must set the following envs: + +- `SEP10_HOME_DOMAINS="localhost:8000, *.stellar.local:8000"`: a comma-separated list of home domains used for [SEP-10]. This should contain the domains of the SDP tenant instances. +- `SEP10_HOME_DOMAIN=""`: this should be an empty string for the Multi-tenant version. +- `SEP10_WEB_AUTH_DOMAIN=`: the home domain of the anchor platform instance. + +### Seggregation of Funds + +In the multi-tenant version, we support the segregation of funds between tenants by configuring the `DISTRIBUTION_SIGNER_TYPE`: + +- When set to `DISTRIBUTION_ACCOUNT_ENV`, the distribution account private key is read from the environment variable `DISTRIBUTION_SEED` and the funds are not seggregated. +- When set to `DISTRIBUTION_ACCOUNT_DB`, the distribution account private key is stored in the database and the funds are seggregated between tenants. The secret is encrypted using the `DISTRIBUTION_ACCOUNT_ENCRYPTION_PASSPHRASE` environment variable. + +The channel accounts on the other hand are shared between tenants, and they are created by the HOST distribution account, set in the `DISTRIBUTION_SEED` environment variable. The channel accounts are encrypted using the `CHANNEL_ACCOUNT_ENCRYPTION_PASSPHRASE` environment variable, or the `DISTRIBUTION_SEED` if the former is not set. In the single-tenant version, the channel accounts were encrypted by the `DISTRIBUTION_SEED`. + +### CLI Commands + +The following CLI commands were updated to become tenant-aware: + +#### Database Migrations & Population + +The single-tenant commands for DB migration and pre-population used to be: + + + +```bash +./stellar-disbursement-platform db migrate up # ⚠️ DECOMISSIONED in 2.x! +./stellar-disbursement-platform db auth migrate up # ⚠️ 2.x REQUIRES A (NEW) TENANT-AWARE FLAG! +./stellar-disbursement-platform db setup-for-network # ⚠️ 2.x REQUIRES A (NEW) TENANT-AWARE FLAG! +``` + + + +The new multi-tenant commands are: + + + +```bash +./stellar-disbursement-platform db admin migrate up +./stellar-disbursement-platform db tss migrate up +./stellar-disbursement-platform db auth migrate up --all +./stellar-disbursement-platform db sdp migrate up --all +./stellar-disbursement-platform db setup-for-network --all +``` + + + +Please notice that some commands require a tenant-aware flag, that can be either: + +- `--all`: to execute these migrations in all tenants. +- `--tenant-id`: to specify the tenant ID to execute the migrations. + +#### Channel Accounts + +The ensure command was updated from using the `--num-channel-accounts-ensure` flag to using a positional argument: + + + +```bash +./stellar-disbursement-platform channel-accounts ensure --num-channel-accounts-ensure 1 # OLD WAY +./stellar-disbursement-platform channel-accounts ensure 1 # NEW WAY +``` + + + +### Database Structure + +In the updated version, the database structure has been revised to accommodate multi-tenancy. As a result, the tables are now distributed across multiple schemas, and new tables have been introduced to support the multi-tenant architecture. The following schemas are used in the multi-tenant version: + +- **admin**: it houses tables associated with tenant administration. It serves as the central point for managing tenant-related information and to resolve tenant schema names based on tenant IDs. None of these tables existed in the single-tenant version. +- **sdp\_\**: are per-tenant schemas that are prefixed with `sdp_`. For example, for tenants BlueCorp and RedCorp, the provisioned schemas would be named `sdp_bluecorp` and `sdp_redcorp`, respectively. These schemas contain all necessary tables for the SDP operation tailored to each tenant, including per-tenant user authentication. +- **tss**: is a schema dedicated to the Transaction Submitter Service (TSS). The TSS tables do not belong to any tenant, although each TSS transaction contains a column that signals which tenant it belongs to. + +These changes allow for the isolation of tenant data per schema, ensuring that each tenant's data is kept separate from other tenants. + +## Step-by-Step Migration Guide + +> EDIT: the code contains a helper script called [`./dev/migrate_1.1.6_to_2.0.0.sh`](https://github.com/stellar/stellar-disbursement-platform-backend/pull/267) that does most of the below steps automatically for you. Keep in mind that you'll need to edit the script with values such as your database DSN, and your tenant name. If you see any errors, you may still need to resort to the steps below to incrementally execute the migration manually. + +Using the new database created from the single-tenant database dump as a starting point (as described in the [Database Backup & Setup](#database-backup--setup-) section), we can now proceed with the migration steps below. + +### Deploy the New Version + +To transaction to a multi-tenant setup, deploy the latest version of the SDP `2+` version. If you're using helm charts, you can get the helm chart from the [SDP Helm Chart repository](https://github.com/stellar/helm-charts/pull/80). + +### Executing Initial Database Migrations + +Following the deployment of the multi-tenant SDP, the next step is to perform the initial **database migrations**. It does not include the tenant-specific tables yet, they will be created later. + +Migration Commands: + + + +```bash +./stellar-disbursement-platform db admin migrate up +./stellar-disbursement-platform db tss migrate up +``` + + + +These commands will create the tenant admin tables on the **admin** schema and the Transaction Submitter Service tables on the **tss** schema, respectively. + +### New Tenant Provisioning Process + +After successfully applying the database migrations, the next step is to provision a new tenant. This is achieved by making an HTTP request to the **Admin API**. + +Be aware that it will provision the tenants with all the per-tenant migrations included. + +#### Starting the SDP API server + +To facilitate tenant provisioning, initiate the SDP Server using the command: + + + +```bash +./stellar-disbursement-platform serve +``` + + + +#### Posting to the Admin API + +- **API port**: The Admin API is accessible on port `8003` by default. This port setting can be adjusted by altering the `ADMIN_PORT` environment variable. +- **Authentication**: Admin API employs Basic Authentication for securing access. To authenticate, populate the request "Authorization" header with `"Authorization: Basic ${Base64(ADMIN_ACCOUNT:ADMIN_API_KEY)}"`. + +Here's a shell script that can be used to create a tenant through the Admin API: + + + +```bash +ADMIN_ACCOUNT="SDP-admin" +ADMIN_API_KEY="api_key_1234567890" +basicAuthCredentials=$(echo -n "$ADMIN_ACCOUNT:$ADMIN_API_KEY" | base64) +AuthHeader="Authorization: Basic $basicAuthCredentials" + +tenant="bluecorp" +baseURL="http://$tenant.stellar.local:8000" +sdpUIBaseURL="http://$tenant.stellar.local:3000" +ownerEmail="owner@$tenant.org" + +curl -X POST http://localhost:8003/tenants \ + -H "Content-Type: application/json" \ + -H "$AuthHeader" \ + -d '{ + "name": "'"$tenant"'", + "organization_name": "Blue Corp", + "base_url": "'"$baseURL"'", + "sdp_ui_base_url": "'"$sdpUIBaseURL"'", + "owner_email": "'"$ownerEmail"'", + "owner_first_name": "john", + "owner_last_name": "doe" + }' +``` + + + +> TODO: check if `base_url` and `sdp_ui_base_url` should be removed after https://stellarorg.atlassian.net/browse/SDP-1148 is done. + +In the SDP Multi-tenant, certain configurations previously managed through environment variables in the single-tenant setup are now stored within the **tenants** table in the admin schema. This change allows each tenant to have its own custom configuration. + +The field **name** is important because it's the tenant identifier. The other fields can be set to the same values used on the environment variables used on the non-tenant version. + +### Importing your data + +Now that we've provisioned a new tenant, we can import our data into it. We need to copy our old tables' data to the new tenant schema. + +Please notice that the following tables don't need to be copied: + +- **_gorp_migrations_** +- **_auth_migrations_** +- **_countries_** +- **_organizations_** + +To import your data from the single-tenant structure, we'll start by removing pre-existing multi-tenant entries that were automatically added when provisioning the tenant: + + + +```sql +BEGIN TRANSACTION; + +DELETE FROM sdp_.auth_users; +DELETE FROM sdp_.wallets_assets; +DELETE FROM sdp_.assets; +DELETE FROM sdp_.wallets; + +COMMIT; +``` + + + +Now we can import the data for the remaining tenant tables. Please notice that some tables cannot be imported directly due to a custom-type conflict. For instance, the `status` column in the `public.payments` table depends on `public.payment_status` enum type, while the one in the `sdp_.payments` table depends on the `sdp_.payment_status` enum type. To solve this, we update the type in the source table to match the destination table type: + + + +```sql +-- INSERT new data: +BEGIN TRANSACTION; + +-- These tables can be copied without changing any types in the source table columns: +INSERT INTO sdp_.wallets SELECT * FROM public.wallets; +INSERT INTO sdp_.assets SELECT * FROM public.assets; +INSERT INTO sdp_.wallets_assets SELECT * FROM public.wallets_assets; +INSERT INTO sdp_.auth_users SELECT * FROM public.auth_users; +INSERT INTO sdp_.receivers SELECT * FROM public.receivers; +INSERT INTO sdp_.auth_user_mfa_codes SELECT * FROM public.auth_user_mfa_codes; +INSERT INTO sdp_.auth_user_password_reset SELECT * FROM public.auth_user_password_reset; + +-- These tables need to have the type of some columns changed, we do that with the `ALTER TABLE` directives: +-- NOTE: we're not reverting the types back to the original ones, as the source tables will be dropped after the migration. +ALTER TABLE public.receiver_wallets + ALTER COLUMN status DROP DEFAULT, + ALTER COLUMN status TYPE sdp_.receiver_wallet_status + USING status::text::sdp_.receiver_wallet_status; +INSERT INTO sdp_.receiver_wallets SELECT * FROM public.receiver_wallets; + +ALTER TABLE public.receiver_verifications + ALTER COLUMN verification_field TYPE sdp_.verification_type + USING verification_field::text::sdp_.verification_type; +INSERT INTO sdp_.receiver_verifications SELECT * FROM public.receiver_verifications; + +ALTER TABLE public.disbursements + ALTER COLUMN status DROP DEFAULT, + ALTER COLUMN status TYPE sdp_.disbursement_status + USING status::text::sdp_.disbursement_status; +ALTER TABLE public.disbursements + ALTER COLUMN verification_field DROP DEFAULT, + ALTER COLUMN verification_field TYPE sdp_.verification_type + USING verification_field::text::sdp_.verification_type; +INSERT INTO sdp_.disbursements SELECT * FROM public.disbursements; + +ALTER TABLE public.payments + ALTER COLUMN status DROP DEFAULT, + ALTER COLUMN status TYPE sdp_.payment_status + USING status::text::sdp_.payment_status; +INSERT INTO sdp_.payments SELECT * FROM public.payments; + +ALTER TABLE public.messages + ALTER COLUMN status DROP DEFAULT, + ALTER COLUMN status TYPE sdp_.message_status + USING status::text::sdp_.message_status; +ALTER TABLE public.messages + ALTER COLUMN type TYPE sdp_.message_type + USING type::text::sdp_.message_type; +INSERT INTO sdp_.messages SELECT * FROM public.messages; + +COMMIT; +``` + + + +This concludes the SDP **tenant data** import, so the next step will be to import the Transaction Submitter Service (TSS) data. As a pre-requisite for that, make sure you have exactly one result in from this query and that no fields are empty: + + + +```sql +SELECT id, name, distribution_account_address FROM admin.tenants; +``` + + + +Now we can use these fields to import the TSS data: + + + +```sql +BEGIN TRANSACTION; + +---- 1. add new columns to the transaction_submitter table and populate them +ALTER TABLE public.submitter_transactions + ADD COLUMN tenant_id VARCHAR(36), + ADD COLUMN distribution_account_address VARCHAR(56); +WITH SelectedTenant AS ( + SELECT id AS tenant_id, distribution_account_address + FROM admin.tenants + LIMIT 1 +) +UPDATE public.submitter_transactions SET tenant_id = (SELECT tenant_id FROM SelectedTenant), distribution_account_address = (SELECT distribution_account_address FROM SelectedTenant); + +---- 2. copy values to the new table +INSERT INTO tss.submitter_transactions +SELECT + id, external_id, + status::text::tss.transaction_status AS status, + status_history, status_message, asset_code, asset_issuer, amount, destination, created_at, updated_at, locked_at, started_at, sent_at, completed_at, synced_at, locked_until_ledger_number, stellar_transaction_hash, attempts_count, xdr_sent, xdr_received, tenant_id, distribution_account_address +FROM public.submitter_transactions; + +COMMIT; +``` + + + +This concludes the migration of the SDP data to the multi-tenant version. The next step is to drop the old tables that are no longer needed. + +### Drop Old Tables + +Now, the only missing step is to drop the single-tenant tables that should not be in the multi-tenant database: + + + +```sql +BEGIN TRANSACTION; + +DROP TABLE public.messages CASCADE; +DROP TABLE public.payments CASCADE; +DROP TABLE public.disbursements CASCADE; +DROP TABLE public.receiver_verifications CASCADE; +DROP TABLE public.receiver_wallets CASCADE; +DROP TABLE public.auth_user_password_reset CASCADE; +DROP TABLE public.auth_user_mfa_codes CASCADE; +DROP TABLE public.receivers CASCADE; +DROP TABLE public.auth_users CASCADE; +DROP TABLE public.wallets_assets CASCADE; +DROP TABLE public.assets CASCADE; +DROP TABLE public.wallets CASCADE; +DROP TABLE public.organizations CASCADE; +DROP TABLE public.gorp_migrations CASCADE; +DROP TABLE public.auth_migrations CASCADE; +DROP TABLE public.countries CASCADE; +DROP TABLE public.submitter_transactions CASCADE; +DROP TABLE public.channel_accounts CASCADE; + +COMMIT; +``` + + + +### Conclusion πŸŽ‰ + +This should conclude the data migration from the single-tenant version to the multi-tenant version of the SDP. Please, make sure to run an e2e test to ensure that everything is working as expected. + +[SEP-10]: https://stellar.org/protocol/sep-10 diff --git a/i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/admin-guide/overview.mdx b/i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/admin-guide/overview.mdx new file mode 100644 index 000000000..ef8b511e9 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/admin-guide/overview.mdx @@ -0,0 +1,19 @@ +--- +title: Overview +sidebar_position: 10 +--- + +The entire SDP step-by-step process usually looks something like the following after the SDP is deployed and organizational users have been set up: + +1. The organization funds the SDP’s distribution account with a Stellar-based asset (e.g. USDC) +2. An administrator logs in to the SDP’s dashboard and uploads a CSV file containing the payment information to initiate a new disbursement +3. The SDP sends a text message to every first-time recipient in the CSV inviting them to download a Stellar-enabled wallet application +4. Meanwhile, the SDP immediately begins making payments to each recipient that has already registered a wallet through a prior payment +5. Each first-time recipient clicks a deep link to download the Stellar-enabled wallet application chosen by the organization for this disbursement, downloads the app, and goes through the wallet sign-up process +6. Once the recipient has signed up and their Stellar account has been created, the wallet immediately authenticates with the SDP using parameters from the deep link and opens the SDP registration web view for the recipient to complete verification +7. The user confirms their identity by providing an OTP code sent to their phone number and an additional piece of verification information for security purposes. The SDP supports three different types of verification information: Date of Birth, Personal PIN, and National ID. This information is input by the recipient in a web flow and passes directly to the SDP, meaning the wallet does not need to process or store this information. +8. The SDP verifies the recipient’s information. If it matches the information from the CSV, the SDP automatically makes the payment to the recipient’s Stellar account + +Graphic representation of flow of funds: + +![Flow of Funds](/assets/SDP/SDP1.png) diff --git a/i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/admin-guide/secure-operation-manual.mdx b/i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/admin-guide/secure-operation-manual.mdx new file mode 100644 index 000000000..eeaf4d4e9 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/admin-guide/secure-operation-manual.mdx @@ -0,0 +1,44 @@ +--- +title: Secure Operation Manual +sidebar_position: 41 +--- + +This manual outlines the security measures implemented in the Stellar Disbursement Platform (SDP) to protect the integrity of the platform and its users. By adhering to these guidelines, you can ensure that your use of the SDP is as secure as possible. + +Security is a critical aspect of the SDP. The measures outlined in this document are designed to mitigate risks and enhance the security of the platform. Users are strongly encouraged to follow these guidelines to protect their accounts and operations. + +### Implementation of reCAPTCHA + +Google's reCAPTCHA has been integrated into the SDP to prevent automated attacks and ensure that interactions are performed by humans, not bots. + +ReCAPTCHA is enabled by default and can be disabled in the development environment by setting the `DISABLE_RECAPTCHA` environment variable to `true`. + +**Note:** Disabling reCAPTCHA is not supported for production environments due to security risks. + +### Enforcement of Multi-Factor Authentication + +Multi-Factor Authentication (MFA) provides an additional layer of security to user accounts. It is enforced by default on the SDP and it relies on OTPs sent to the account's email. + +MFA is enabled by default and can be disabled in the development environment by setting the `DISABLE_MFA` environment variable to `true`. + +**Note:** Disabling MFA is not supported for production environments due to security risks. + +### Best Practices for Wallet Management + +The SDP wallet should be used primarily as a hot wallet with a limited amount of funds to minimize potential losses. + +#### Hot and Cold Wallets + +- A hot wallet is connected to the internet and allows for quick transactions. +- A cold wallet is offline and used for storing funds securely. +- Learn more about these concepts at [Investopedia](https://www.investopedia.com/hot-wallet-vs-cold-wallet-7098461). + +### Distribution of Disbursement Responsibilities + +To enhance security, disbursement responsibilities should be distributed among multiple financial controller users. + +#### Recommended Configuration + +1. **Approval Flow**: Enable the approval flow on the organization page to require two users for the disbursement process. The owner can do that at _Profile > Organization > ... > Edit details > Approval flow > Confirm_. +2. **Financial Controller Role**: Create two users with the _Financial Controller_ role on the organization page to enforce separation of duties. The owner can do hat at _Settings > Team Members_. +3. **Owner Account Management**: Use the Owner account solely for user management and organization configuration. Avoid using the Owner account for financial controller tasks to minimize the exposure of that account. diff --git a/i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/admin-guide/user-interface/README.mdx b/i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/admin-guide/user-interface/README.mdx new file mode 100644 index 000000000..1096857c7 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/admin-guide/user-interface/README.mdx @@ -0,0 +1,10 @@ +--- +title: User Interface +sidebar_position: 40 +--- + +import DocCardList from "@theme/DocCardList"; + +A description and walkthrough of the various parts of the SDP user interface. + + diff --git a/i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/admin-guide/user-interface/analytics.mdx b/i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/admin-guide/user-interface/analytics.mdx new file mode 100644 index 000000000..d18660b26 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/admin-guide/user-interface/analytics.mdx @@ -0,0 +1,20 @@ +--- +title: Analytics +sidebar_position: 60 +--- + +The Analytics page provides comprehensive insights into various aspects of financial transactions, enabling the user to track and understand key payment-related metrics. As more metrics and statistics become available, additional tiles will be added to this screen. The page displays information such as the successful payment rate, the total number of successful payments, the number of failed payments, and the number of remaining payments. Additionally, it shows the total amount disbursed, the average amount per transaction, the total amount in USDC, and the number of individuals and wallets involved in the transactions. + +In more detail: + +- The "Successful payment rate" indicates the percentage of payments processed successfully out of total attempted payments. +- "Successful payments" shows the count of all transactions that have been completed successfully. +- "Failed payments" reveals the number of transactions that didn't go through, which can help identify issues with the payment process. +- "Remaining payments" provides the number of transactions that are yet to be processed. +- "Total disbursed" offers information on the total amount of funds that have been sent out. +- The "Average amount" offers an average value of all the transactions that have taken place in USDC. +- "USDC" reveals the total amount of funds in the system, denominated in USDC. +- "Individuals" represents the number of people involved in these transactions. +- "Wallets" indicates the number of unique digital wallets involved in the transactions. + +![Analytics](/assets/SDP/SDP24.png) diff --git a/i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/admin-guide/user-interface/dashboard-home.mdx b/i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/admin-guide/user-interface/dashboard-home.mdx new file mode 100644 index 000000000..a140abb45 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/admin-guide/user-interface/dashboard-home.mdx @@ -0,0 +1,44 @@ +--- +title: Dashboard Home +sidebar_position: 10 +--- + +The main page of the dashboard contains a summary of recent disbursement activity and key performance metrics. + +This includes: + +- Successful payment rate: The percentage of payments completed successfully (pending payments are not counted as successful). +- Successful payments: The total number of payments that have been successfully made. +- Failed payments: The total number of payments that failed to process. +- Remaining payments: The total number of payments that are scheduled but haven't been processed yet. +- Total disbursed: The total amount of funds successfully sent to receivers by an organization over time. +- Individuals: The total number of individuals who are set to receive disbursements. +- Wallets: The total number of wallets used within the SDP. This usually equals the number of individuals but it is possible for each person to have more than one wallet. + +![Dashboard Home](/assets/SDP/SDP19.png) + +On the left side of the Stellar Disbursement Platform dashboard is the organization logo and tabs to help you navigate through the platform. + +They include: + +- Home: This is the main dashboard that provides an overview of your organization’s activities. +- Disbursements: This section shows you the history and details of all disbursements. +- Receivers: Lists of individuals who are set to receive disbursements. +- Payments: Here you can find the history and granular details of all payments. +- Wallets: Information related to your organization’s wallet, the source of funds for your disbursements. +- Analytics: Data visualization tools to help you analyze your disbursements and payments. +- Profile: Manage your personal and organizational information. +- Settings: Adjust the settings of the SDP according to your preference. + +The dashboard also shows a Recent Disbursements list, providing a quick snapshot of your most recent disbursements. + +Each entry shows: + +- Disbursement Name: The unique name given by your organization to the disbursement operation. +- Total payments: Total number of payments within the specific disbursement. +- Successful: Number of payments that have been successfully sent from the SDP Distribution Wallet to receiver wallets so far. +- Failed: Number of payments that failed to process. +- Remaining: Number of payments that are scheduled but haven't been processed yet, usually because the receiver has not yet set up a wallet. +- Created at: The time and date the disbursement was created, displayed in your local timezone. +- Total amount: The total value of the disbursement in the appropriate asset. +- Amount disbursed: The amount of the disbursement that has been successfully paid out so far. diff --git a/i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/admin-guide/user-interface/disbursements.mdx b/i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/admin-guide/user-interface/disbursements.mdx new file mode 100644 index 000000000..31757f6db --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/admin-guide/user-interface/disbursements.mdx @@ -0,0 +1,26 @@ +--- +title: Disbursements +sidebar_position: 20 +--- + +The Disbursements page provides a paginated list of all disbursements, detailing each disbursement's status and related payment information. + +![Disbursements](/assets/SDP/SDP20.png) + +The page contains the following: + +- Drafts: Click the Drafts button at the top right to go to a list of disbursements that have been created but not yet submitted. +- New disbursement: Click the New Disbursement button to start the process of creating a new disbursement. +- Search by disbursement name: Input the name of a disbursement to quickly find specific details. +- Filter: Allows you to narrow down the disbursement list based on specific criteria like status or creation date. +- Export: Use this option to download the disbursement data in CSV format. +- Disbursement detail: Each disbursement is displayed with the following details: + - Disbursement name: The unique name assigned to the disbursement by your organization. + - Total payments: The total number of payments within the disbursement. + - Successful: The number of payments within the disbursement that have been processed successfully from the distribution account to registered wallets. + - Failed: The number of payments that failed during processing. + - Remaining: The number of payments that are yet to be processed. + - Created at: The date and time when the disbursement was created. + - Total amount: The total value of the disbursement in the appropriate asset. + - Amount disbursed: The amount of the disbursement that has already been paid out. +- You can click into an individual disbursement to see its details, including a full list of receivers and payments. diff --git a/i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/admin-guide/user-interface/payments.mdx b/i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/admin-guide/user-interface/payments.mdx new file mode 100644 index 000000000..0b67b4eff --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/admin-guide/user-interface/payments.mdx @@ -0,0 +1,22 @@ +--- +title: Payments +sidebar_position: 40 +--- + +The Payments page provides a list of all payments, detailing each payment's status and related information. + +![Payments](/assets/SDP/SDP22.png) + +The Payments page includes: + +- Search by payment ID: Enter a payment ID to find specific payment details quickly. +- Filter: This tool allows you to narrow down the payment list based on specific criteria. +- Export: This option lets you download payments data in CSV format. +- Payment Details: Each payment is listed with the following details: + - Payment ID: A unique identifier assigned to each payment. + - Wallet address: The digital wallet address where the payment is sent. A dash ("-") signifies that the wallet address is not yet set. The payment cannot be made until the receiver wallet is created and linked in the SDP. + - Disbursement name: The name of the disbursement associated with the payment. + - Completed at: The date and time when the payment was completed. A dash ("-") signifies that the payment has not yet been completed. + - Amount: The value of the payment in the appropriate asset. + - Status: The current status of the payment. This can be "Success" if the payment has been completed, β€œPending” if the payment is currently processing on the Stellar network, or "Ready" if the payment is yet to be processed. +- You can click into an individual payment to see its details, including a granular status history and Stellar blockchain details. diff --git a/i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/admin-guide/user-interface/receivers.mdx b/i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/admin-guide/user-interface/receivers.mdx new file mode 100644 index 000000000..4ab11b05b --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/admin-guide/user-interface/receivers.mdx @@ -0,0 +1,24 @@ +--- +title: Receivers +sidebar_position: 30 +--- + +The Receivers page displays a list of individuals set to receive payments, with wallet information and payment history. This information allows you to track and manage the payments made to each receiver, and provides a snapshot of each receiver's interaction with a disbursement. + +![Receivers](/assets/SDP/SDP20x.png) + +The Receivers page includes the following: + +- Search and Filter - At the top of the Receivers page, there are several tools available to help you find specific information: + - Search by phone number: Enter the phone number of a receiver to quickly find their information. + - Filter: Use this tool to narrow down the list of receivers based on specific criteria. + - Export: This allows you to download the receiver data in CSV format. +- Receiver Details: Each receiver is listed with the following details: + - Phone number: The receiver's phone number, which serves as a unique identifier within the SDP. + - Wallet provider(s): The provider of the receiver's digital wallet (usually a non-custodial app on a person’s phone). + - Wallets registered: The number of wallets registered and successfully linked to the SDP per receiver. A dash ("-") indicates no wallet has been registered. + - Total payments: The total number of payments intended for the receiver. + - Successful: The number of payments that have been successfully sent to the receiver’s wallet. + - Created at: The time and date the receiver was created in the system, displayed in your local timezone. + - Amount(s) received: The total amount the receiver has successfully received in the appropriate asset(s). +- You can click into an individual receiver to see their details, including their linked wallets and full payments history. diff --git a/i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/admin-guide/user-interface/wallets.mdx b/i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/admin-guide/user-interface/wallets.mdx new file mode 100644 index 000000000..28c9e8599 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/admin-guide/user-interface/wallets.mdx @@ -0,0 +1,19 @@ +--- +title: Wallets +sidebar_position: 50 +--- + +The Wallets page provides detailed information about your distribution account, which is the primary Stellar account from which your disbursements are made. + +![Wallets](/assets/SDP/SDP23.png) + +The Wallets page includes the following: + +- Distribution account public key: This is your unique identifier for your distribution account on the Stellar network. You use this public key to receive funds in your distribution account. +- Balance: This section displays the current balance of different digital assets in your distribution account: + - USDC, EUROC, etc: This is the current balance available for making payments within a disbursement. + - XLM: This is the balance of Stellar Lumens. This is used to fund the distribution account (base reserve) and transaction fees associated with making payments. This is for informational purposes and is not the source of funds for disbursements. In general, you do not need to worry about maintaining this, as Stellar network fees are very low. + +### Adding Funds + +Add funds to your distribution account: You can deposit Stellar-based digital assets into your distribution account by sending them to the provided public key. Make sure your account has a trustline to the asset before you send funds. As a general principle, do not use your distribution account as a long-term holding place for money. It is meant to be a pass-through wallet to fund disbursements. diff --git a/i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/api-reference/README.mdx b/i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/api-reference/README.mdx new file mode 100644 index 000000000..5611fc6ae --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/api-reference/README.mdx @@ -0,0 +1,10 @@ +--- +title: API Reference +sidebar_position: 20 +--- + +import DocCardList from "@theme/DocCardList"; + +View all Stellar Disbursement Platform API information. + + diff --git a/i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/api-reference/resources/README.mdx b/i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/api-reference/resources/README.mdx new file mode 100644 index 000000000..d20ee7766 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/api-reference/resources/README.mdx @@ -0,0 +1,25 @@ +--- +title: Resources +sidebar_position: 20 +--- + +import {MethodTable} from "@site/src/components/MethodTable"; + +Data on the Stellar Disbursement Platform is organized according to resources. Each resource has several different endpoints. + + + +| | | +| ------------------------------------------------------------------ | - | +| [Admin (Tenant Management)](./admin/README.mdx) | | +| [Authentication](./auth/README.mdx) | | +| [Disbursements](./disbursements/README.mdx) | | +| [Organization](./organization/README.mdx) | | +| [Payments](./payments/README.mdx) | | +| [Profiles](./profile/README.mdx) | | +| [Receivers](./receivers/README.mdx) | | +| [Registration](./registration/README.mdx) | | +| [Statistics](./statistics/README.mdx) | | +| [Users](./users/README.mdx) | | + + diff --git a/i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/api-reference/resources/admin/README.mdx b/i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/api-reference/resources/admin/README.mdx new file mode 100644 index 000000000..21c948d78 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/api-reference/resources/admin/README.mdx @@ -0,0 +1,20 @@ +--- +title: Admin (Tenant Management) +order: 9 +--- + +import {EndpointsTable} from "@site/src/components/EndpointsTable"; + +The Admin API oversees the management of tenants within the system, facilitating tasks such as provisioning new tenants, updating their information, and retrieving tenant data. + + + +| | | +| ------ | ----------------------------------------------- | +| GET | [/tenants](../get-all-tenants.api.mdx) | +| POST | [/tenants](../create-tenant.api.mdx) | +| GET | [/tenants/:arg](../retrieve-a-tenant.api.mdx) | +| PATCH | [/tenants/:id](../update-a-tenant.api.mdx) | +| DELETE | [/tenants/:id](../soft-delete-a-tenant.api.mdx) | + + diff --git a/i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/api-reference/resources/auth/README.mdx b/i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/api-reference/resources/auth/README.mdx new file mode 100644 index 000000000..d485df7fe --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/api-reference/resources/auth/README.mdx @@ -0,0 +1,20 @@ +--- +title: Authentication +order: 0 +--- + +import {EndpointsTable} from "@site/src/components/EndpointsTable"; + +Authentication controls the log in/log out process for all SDP users, as well as the token refresh process. Authentication uses a JWT approach signed with an ES256 private key. + + + +| | | +| ---- | ---------------------------------------------- | +| POST | [/login](../log-in.api.mdx) | +| POST | [/refresh-token](../refresh-token.api.mdx) | +| POST | [/mfa](../authenticate-mfa.api.mdx) | +| POST | [/forgot-password](../forgot-password.api.mdx) | +| POST | [/reset-password](../reset-password.api.mdx) | + + diff --git a/i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/api-reference/resources/disbursements/README.mdx b/i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/api-reference/resources/disbursements/README.mdx new file mode 100644 index 000000000..632e75c35 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/api-reference/resources/disbursements/README.mdx @@ -0,0 +1,22 @@ +--- +title: Disbursements +order: 1 +--- + +import {EndpointsTable} from "@site/src/components/EndpointsTable"; + +A disbursement is a group of payments sent to multiple individuals at once. An SDP user with the appropriate role triggers a new disbursement through the SDP dashboard by uploading a list of receivers and amounts. When the receiver has linked their wallet to the SDP, the payment automatically begins. SDP users can track their disbursements in real-time through the SDP dashboard. Each disbursement must have a unique name defined by the organization. + + + +| | | +| ----- | -------------------------------------------------------------------------------- | +| GET | [/disbursements](../list-all-disbursements.api.mdx) | +| POST | [/disbursements](../create-disbursement.api.mdx) | +| GET | [/disbursements/:id](../retrieve-a-disbursement.api.mdx) | +| GET | [/disbursements/:id/receivers](../list-all-disbursement-receivers.api.mdx) | +| POST | [/disbursements/:id/instructions](../upload-disbursement-instructions.api.mdx) | +| GET | [/disbursements/:id/instructions](../download-disbursement-instructions.api.mdx) | +| PATCH | [/disbursements/:id/status](../update-a-disbursement-status.api.mdx) | + + diff --git a/i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/api-reference/resources/organization/README.mdx b/i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/api-reference/resources/organization/README.mdx new file mode 100644 index 000000000..79b1a9049 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/api-reference/resources/organization/README.mdx @@ -0,0 +1,23 @@ +--- +title: Organization +order: 2 +--- + +import {EndpointsTable} from "@site/src/components/EndpointsTable"; + +Organization endpoints manage the process of getting and updating organizational profile information. The organization’s profile has basic information set at the time of SDP deployment. It can be modified by the Owner. Organizations can also manage their preferences, like which assets to use, through these endpoints. + + + +| | | +| ------ | ------------------------------------------------------- | +| GET | [/organization](../get-organization-info.api.mdx) | +| PATCH | [/organization](../update-organization-profile.api.mdx) | +| GET | [/organization/logo](../get-organization-logo.api.mdx) | +| GET | [/countries](../get-all-countries.api.mdx) | +| GET | [/assets](../get-all-assets.api.mdx) | +| POST | [/assets](../create-asset.api.mdx) | +| DELETE | [/assets/:id](../delete-asset.api.mdx) | +| GET | [/wallets](../get-all-wallets.api.mdx) | + + diff --git a/i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/api-reference/resources/payments/README.mdx b/i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/api-reference/resources/payments/README.mdx new file mode 100644 index 000000000..d87dee5eb --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/api-reference/resources/payments/README.mdx @@ -0,0 +1,17 @@ +--- +title: Payments +order: 3 +--- + +import {EndpointsTable} from "@site/src/components/EndpointsTable"; + +An SDP payment is an individual payment from an organization to a receiver. Each payment is part of a disbursement and occurs on the Stellar network. Granular payment status is stored in the SDP database and can be viewed in real-time on the SDP dashboard. There is no POST endpoint because submitting payments to the Stellar network is handled by the Transaction Submission Service (TSS). + + + +| | | +| --- | ---------------------------------------------- | +| GET | [/payments](../list-all-payments.api.mdx) | +| GET | [/payments/:id](../retrieve-a-payment.api.mdx) | + + diff --git a/i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/api-reference/resources/profile/README.mdx b/i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/api-reference/resources/profile/README.mdx new file mode 100644 index 000000000..e96d173f0 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/api-reference/resources/profile/README.mdx @@ -0,0 +1,17 @@ +--- +title: Profile +order: 4 +--- + +import {EndpointsTable} from "@site/src/components/EndpointsTable"; + +Profiles endpoints manage the process of getting and updating individual profile information. Profile information is set when the account is created and can be updated by the user on the SDP dashboard Profile page. Note: profiles never refer to receivers of funds. + + + +| | | +| ----- | ------------------------------------------ | +| GET | [/profile](../get-profile.api.mdx) | +| PATCH | [/profile](../update-user-profile.api.mdx) | + + diff --git a/i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/api-reference/resources/receivers/README.mdx b/i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/api-reference/resources/receivers/README.mdx new file mode 100644 index 000000000..18be2355c --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/api-reference/resources/receivers/README.mdx @@ -0,0 +1,20 @@ +--- +title: Receivers +order: 5 +--- + +import {EndpointsTable} from "@site/src/components/EndpointsTable"; + +A receiver is an individual receiving a payment in a disbursement. The receiver is tracked by phone number to reduce the need for personally identifiable information. Each receiver must be unique within the disbursement. + +Each receiver will have at least one wallet associated with them. The wallet public key will remain null until the receiver registers with a wallet provider and links the wallet to the SDP through SEP-24. Receivers must verify their identity through that process, which requires the SDP to store verification information on receivers like date of birth, national ID number, or personal PIN. This information can be updated by the organization through the receiver endpoints. + + + +| | | +| ----- | ------------------------------------------------ | +| GET | [/receivers](../list-all-receivers.api.mdx) | +| GET | [/receivers/:id](../retrieve-a-receiver.api.mdx) | +| PATCH | [/receivers/:id](../update-a-receiver.api.mdx) | + + diff --git a/i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/api-reference/resources/registration/README.mdx b/i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/api-reference/resources/registration/README.mdx new file mode 100644 index 000000000..51ec9982e --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/api-reference/resources/registration/README.mdx @@ -0,0 +1,33 @@ +--- +title: Registration +order: 6 +--- + +import {EndpointsTable} from "@site/src/components/EndpointsTable"; + +The registration endpoints guide the process for a receiver to verify their identity and link their wallet address to an SDP. The registration process only needs to happen once per receiver to link their wallet. Only SDP-compatible wallet providers can facilitate the registration process. These endpoints must be supported and hit by the wallet providers after the receiver gets the initial SMS invite. After the wallet address is successfully linked, the payment automatically begins. + +There are two parts to the registration flow. First, the wallet must authenticate and initiate a registration flow using the Anchor Platform Endpoints defined below. Note that these endpoints are hosted on a different host than the Stellar Disursement Platform. + +The second part of the registration flow is handled by the webview that is opened within the wallet application. This webview uses the endpoints defined in the Stellar Disbursement Platfrom Endpoints section to complete the registration process. The wallet application can chose not to use the webview and intstead integrate directly with the API. + + + +| | | +| ---- | ----------------------------------------------------------------------------------------------- | +| GET | [/.well-known/stellar.toml](../retrieve-stellar-info-file.api.mdx) | +| GET | [WEB_AUTH_ENDPOINT](../request-challenge-transaction.api.mdx) | +| POST | [WEB_AUTH_ENDPOINT](../provide-signed-challenge-transaction.api.mdx) | +| POST | [TRANSFER_SERVER_SEP0024/transactions/deposit/interactive](../request-registration-url.api.mdx) | + + + + + +| | | +| ---- | ---------------------------------------------------------------------------- | +| GET | [/wallet-registration/start](../start-wallet-registration.api.mdx) | +| POST | [/wallet-registration/otp](../send-one-time-passcode.api.mdx) | +| POST | [/wallet-registration/verification](../verify-receiver-registration.api.mdx) | + + diff --git a/i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/api-reference/resources/sidebar.ts b/i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/api-reference/resources/sidebar.ts new file mode 100644 index 000000000..16a15fcbf --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/api-reference/resources/sidebar.ts @@ -0,0 +1,283 @@ +import type { SidebarsConfig } from "@docusaurus/plugin-content-docs"; +const sidebar: SidebarsConfig = { + apisidebar: [{ + type: "doc", + id: "stellar-disbursement-platform/api-reference/resources/stellar-disbursement-platform-api" + }, { + type: "category", + label: "Authentication", + items: [{ + type: "doc", + id: "stellar-disbursement-platform/api-reference/resources/log-in", + label: "Log In", + className: "api-method post" + }, { + type: "doc", + id: "stellar-disbursement-platform/api-reference/resources/refresh-token", + label: "Refresh Token", + className: "api-method post" + }, { + type: "doc", + id: "stellar-disbursement-platform/api-reference/resources/authenticate-mfa", + label: "Provide Multi-Factor Authentication", + className: "api-method post" + }, { + type: "doc", + id: "stellar-disbursement-platform/api-reference/resources/forgot-password", + label: "Forgot Password", + className: "api-method post" + }, { + type: "doc", + id: "stellar-disbursement-platform/api-reference/resources/reset-password", + label: "Reset Rassword", + className: "api-method post" + }] + }, { + type: "category", + label: "Disbursements", + items: [{ + type: "doc", + id: "stellar-disbursement-platform/api-reference/resources/list-all-disbursements", + label: "List All Disbursements", + className: "api-method get" + }, { + type: "doc", + id: "stellar-disbursement-platform/api-reference/resources/create-disbursement", + label: "Create Disbursement", + className: "api-method post" + }, { + type: "doc", + id: "stellar-disbursement-platform/api-reference/resources/retrieve-a-disbursement", + label: "Retrieve a Disbursement", + className: "api-method get" + }, { + type: "doc", + id: "stellar-disbursement-platform/api-reference/resources/list-all-disbursement-receivers", + label: "List All Disbursement Receivers", + className: "api-method get" + }, { + type: "doc", + id: "stellar-disbursement-platform/api-reference/resources/upload-disbursement-instructions", + label: "Upload Disbursement Instructions", + className: "api-method post" + }, { + type: "doc", + id: "stellar-disbursement-platform/api-reference/resources/download-disbursement-instructions", + label: "Download Disbursement Instructions", + className: "api-method get" + }, { + type: "doc", + id: "stellar-disbursement-platform/api-reference/resources/update-a-disbursement-status", + label: "Update a Disbursement Status", + className: "api-method patch" + }] + }, { + type: "category", + label: "Payments", + items: [{ + type: "doc", + id: "stellar-disbursement-platform/api-reference/resources/list-all-payments", + label: "List All Payments", + className: "api-method get" + }, { + type: "doc", + id: "stellar-disbursement-platform/api-reference/resources/retrieve-a-payment", + label: "Retrieve a Payment", + className: "api-method get" + }] + }, { + type: "category", + label: "Receivers", + items: [{ + type: "doc", + id: "stellar-disbursement-platform/api-reference/resources/list-all-receivers", + label: "List All Receivers", + className: "api-method get" + }, { + type: "doc", + id: "stellar-disbursement-platform/api-reference/resources/retrieve-a-receiver", + label: "Retrieve a Receiver", + className: "api-method get" + }, { + type: "doc", + id: "stellar-disbursement-platform/api-reference/resources/update-a-receiver", + label: "Update a Receiver", + className: "api-method patch" + }] + }, { + type: "category", + label: "Statistics", + items: [{ + type: "doc", + id: "stellar-disbursement-platform/api-reference/resources/retrieve-all-statistics", + label: "Retrieve All Statistics", + className: "api-method get" + }, { + type: "doc", + id: "stellar-disbursement-platform/api-reference/resources/retrieve-disbursement-statistics", + label: "Retrieve Disbursement Statistics", + className: "api-method get" + }] + }, { + type: "category", + label: "Registration", + items: [{ + type: "doc", + id: "stellar-disbursement-platform/api-reference/resources/start-wallet-registration", + label: "Start Wallet Registration", + className: "api-method get" + }, { + type: "doc", + id: "stellar-disbursement-platform/api-reference/resources/send-one-time-passcode", + label: "Send One-Time Passcode", + className: "api-method post" + }, { + type: "doc", + id: "stellar-disbursement-platform/api-reference/resources/verify-receiver-registration", + label: "Verify Receiver Registration", + className: "api-method post" + }, { + type: "doc", + id: "stellar-disbursement-platform/api-reference/resources/retrieve-stellar-info-file", + label: "Retrieve Stellar Info File", + className: "api-method get" + }, { + type: "doc", + id: "stellar-disbursement-platform/api-reference/resources/request-challenge-transaction", + label: "Request Challenge Transaction", + className: "api-method get" + }, { + type: "doc", + id: "stellar-disbursement-platform/api-reference/resources/provide-signed-challenge-transaction", + label: "Provide Signed Challenge Transaction", + className: "api-method post" + }, { + type: "doc", + id: "stellar-disbursement-platform/api-reference/resources/request-registration-url", + label: "Request Registration URL", + className: "api-method post" + }] + }, { + type: "category", + label: "Profile", + items: [{ + type: "doc", + id: "stellar-disbursement-platform/api-reference/resources/get-profile", + label: "Get Profile", + className: "api-method get" + }, { + type: "doc", + id: "stellar-disbursement-platform/api-reference/resources/update-user-profile", + label: "Update User Profile", + className: "api-method patch" + }] + }, { + type: "category", + label: "Organization", + items: [{ + type: "doc", + id: "stellar-disbursement-platform/api-reference/resources/get-organization-info", + label: "Get Organization Info", + className: "api-method get" + }, { + type: "doc", + id: "stellar-disbursement-platform/api-reference/resources/update-organization-profile", + label: "Update Organization Profile", + className: "api-method patch" + }, { + type: "doc", + id: "stellar-disbursement-platform/api-reference/resources/get-organization-logo", + label: "Retrieve Organization Logo", + className: "api-method get" + }, { + type: "doc", + id: "stellar-disbursement-platform/api-reference/resources/get-all-countries", + label: "Get All Countries", + className: "api-method get" + }, { + type: "doc", + id: "stellar-disbursement-platform/api-reference/resources/get-all-assets", + label: "Get All Assets", + className: "api-method get" + }, { + type: "doc", + id: "stellar-disbursement-platform/api-reference/resources/create-asset", + label: "Create Asset", + className: "api-method post" + }, { + type: "doc", + id: "stellar-disbursement-platform/api-reference/resources/delete-asset", + label: "Delete Asset", + className: "api-method delete" + }, { + type: "doc", + id: "stellar-disbursement-platform/api-reference/resources/get-all-wallets", + label: "Get All Wallets", + className: "api-method get" + }] + }, { + type: "category", + label: "Users", + items: [{ + type: "doc", + id: "stellar-disbursement-platform/api-reference/resources/get-all-users", + label: "Get All Users", + className: "api-method get" + }, { + type: "doc", + id: "stellar-disbursement-platform/api-reference/resources/create-user", + label: "Create User", + className: "api-method post" + }, { + type: "doc", + id: "stellar-disbursement-platform/api-reference/resources/update-user-activation-status", + label: "Update User Activation Status", + className: "api-method patch" + }, { + type: "doc", + id: "stellar-disbursement-platform/api-reference/resources/get-all-roles", + label: "Get All Roles", + className: "api-method get" + }, { + type: "doc", + id: "stellar-disbursement-platform/api-reference/resources/update-user-role", + label: "Update User Role", + className: "api-method patch" + }] + }, { + type: "category", + label: "Admin", + items: [{ + type: "doc", + id: "stellar-disbursement-platform/api-reference/resources/get-all-tenants", + label: "Get All Tenants", + className: "api-method get" + }, { + type: "doc", + id: "stellar-disbursement-platform/api-reference/resources/create-tenant", + label: "Create Tenant", + className: "api-method post" + }, { + type: "doc", + id: "stellar-disbursement-platform/api-reference/resources/retrieve-a-tenant", + label: "Retrieve a Tenant", + className: "api-method get" + }, { + type: "doc", + id: "stellar-disbursement-platform/api-reference/resources/soft-delete-a-tenant", + label: "Soft delete a Tenant", + className: "api-method delete" + }, { + type: "doc", + id: "stellar-disbursement-platform/api-reference/resources/update-a-tenant", + label: "Update a Tenant", + className: "api-method patch" + }, { + type: "doc", + id: "stellar-disbursement-platform/api-reference/resources/default-tenant", + label: "Default Tenant", + className: "api-method post" + }] + }] +}; +export default sidebar.apisidebar; \ No newline at end of file diff --git a/i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/api-reference/resources/statistics/README.mdx b/i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/api-reference/resources/statistics/README.mdx new file mode 100644 index 000000000..c63be1013 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/api-reference/resources/statistics/README.mdx @@ -0,0 +1,15 @@ +--- +title: Statistics +order: 7 +--- + +Statistics endpoints return general aggregated data per organization, as well as disbursement-specific metrics. SDP users can use this data to monitor their disbursements over time. + + + +| | | +| --- | ---------------------------------------------------------------------------- | +| GET | [/statistics](../retrieve-all-statistics.api.mdx) | +| GET | [/statistics/disbursements/:id](../retrieve-disbursement-statistics.api.mdx) | + + diff --git a/i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/api-reference/resources/users/README.mdx b/i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/api-reference/resources/users/README.mdx new file mode 100644 index 000000000..8e837bf41 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs-platforms/current/stellar-disbursement-platform/api-reference/resources/users/README.mdx @@ -0,0 +1,18 @@ +--- +title: Users +order: 8 +--- + +The users endpoints facilitate the creation of new SDP users–including setting the appropriate role, sending an email invitation, and activating a user–and managing roles. + + + +| | | +| ----- | ------------------------------------------------------------- | +| GET | [/users](../get-all-users.api.mdx) | +| POST | [/users](../create-user.api.mdx) | +| PATCH | [/users/activation](../update-user-activation-status.api.mdx) | +| GET | [/users/roles](../get-all-roles.api.mdx) | +| PATCH | [/users/roles](../update-user-role.api.mdx) | + + diff --git a/i18n/es/docusaurus-plugin-content-docs/current.json b/i18n/es/docusaurus-plugin-content-docs/current.json new file mode 100644 index 000000000..5d9f7ce37 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs/current.json @@ -0,0 +1,358 @@ +{ + "version.label": { + "message": "Next", + "description": "The label for version current" + }, + "sidebar.build.category.Write Smart Contracts": { + "message": "Write Smart Contracts", + "description": "The label for category Write Smart Contracts in sidebar build" + }, + "sidebar.build.category.Getting Started": { + "message": "Getting Started", + "description": "The label for category Getting Started in sidebar build" + }, + "sidebar.build.category.Example Contracts": { + "message": "Example Contracts", + "description": "The label for category Example Contracts in sidebar build" + }, + "sidebar.build.category.Build Applications": { + "message": "Build Applications", + "description": "The label for category Build Applications in sidebar build" + }, + "sidebar.build.category.Build a Wallet with the Wallet SDK": { + "message": "Build a Wallet with the Wallet SDK", + "description": "The label for category Build a Wallet with the Wallet SDK in sidebar build" + }, + "sidebar.build.category.Build a Payment App with the JS SDK": { + "message": "Build a Payment App with the JS SDK", + "description": "The label for category Build a Payment App with the JS SDK in sidebar build" + }, + "sidebar.build.category.Anchor Integration": { + "message": "Anchor Integration", + "description": "The label for category Anchor Integration in sidebar build" + }, + "sidebar.build.category.Build Custom Network Ingestion Pipeline": { + "message": "Build Custom Network Ingestion Pipeline", + "description": "The label for category Build Custom Network Ingestion Pipeline in sidebar build" + }, + "sidebar.build.category.How-To Guides": { + "message": "How-To Guides", + "description": "The label for category How-To Guides in sidebar build" + }, + "sidebar.build.category.Contract Conventions": { + "message": "Contract Conventions", + "description": "The label for category Contract Conventions in sidebar build" + }, + "sidebar.build.category.Dapp Development": { + "message": "Dapp Development", + "description": "The label for category Dapp Development in sidebar build" + }, + "sidebar.build.category.Events": { + "message": "Events", + "description": "The label for category Events in sidebar build" + }, + "sidebar.build.category.Fees & Metering": { + "message": "Fees & Metering", + "description": "The label for category Fees & Metering in sidebar build" + }, + "sidebar.build.category.Freighter Wallet": { + "message": "Freighter Wallet", + "description": "The label for category Freighter Wallet in sidebar build" + }, + "sidebar.build.category.RPC": { + "message": "RPC", + "description": "The label for category RPC in sidebar build" + }, + "sidebar.build.category.State Archival": { + "message": "State Archival", + "description": "The label for category State Archival in sidebar build" + }, + "sidebar.build.category.Stellar Basics": { + "message": "Stellar Basics", + "description": "The label for category Stellar Basics in sidebar build" + }, + "sidebar.build.category.Stellar CLI": { + "message": "Stellar CLI", + "description": "The label for category Stellar CLI in sidebar build" + }, + "sidebar.build.category.Storage": { + "message": "Storage", + "description": "The label for category Storage in sidebar build" + }, + "sidebar.build.category.Testing": { + "message": "Testing", + "description": "The label for category Testing in sidebar build" + }, + "sidebar.build.category.Transactions": { + "message": "Transactions", + "description": "The label for category Transactions in sidebar build" + }, + "sidebar.build.category.Type Conversions": { + "message": "Type Conversions", + "description": "The label for category Type Conversions in sidebar build" + }, + "sidebar.learn.category.Core Concepts": { + "message": "Core Concepts", + "description": "The label for category Core Concepts in sidebar learn" + }, + "sidebar.learn.category.Stellar Data Structures": { + "message": "Stellar Data Structures", + "description": "The label for category Stellar Data Structures in sidebar learn" + }, + "sidebar.learn.category.Operations & Transactions": { + "message": "Operations & Transactions", + "description": "The label for category Operations & Transactions in sidebar learn" + }, + "sidebar.learn.category.Encyclopedia": { + "message": "Encyclopedia", + "description": "The label for category Encyclopedia in sidebar learn" + }, + "sidebar.learn.category.Contract Development": { + "message": "Contract Development", + "description": "The label for category Contract Development in sidebar learn" + }, + "sidebar.learn.category.Types": { + "message": "Types", + "description": "The label for category Types in sidebar learn" + }, + "sidebar.learn.category.Contract Interactions": { + "message": "Contract Interactions", + "description": "The label for category Contract Interactions in sidebar learn" + }, + "sidebar.learn.category.Transactions (specialized)": { + "message": "Transactions (specialized)", + "description": "The label for category Transactions (specialized) in sidebar learn" + }, + "sidebar.learn.category.Security": { + "message": "Security", + "description": "The label for category Security in sidebar learn" + }, + "sidebar.learn.category.Storage": { + "message": "Storage", + "description": "The label for category Storage in sidebar learn" + }, + "sidebar.learn.category.Errors and Debugging": { + "message": "Errors and Debugging", + "description": "The label for category Errors and Debugging in sidebar learn" + }, + "sidebar.learn.category.Data Format": { + "message": "Data Format", + "description": "The label for category Data Format in sidebar learn" + }, + "sidebar.learn.category.Network Configuration": { + "message": "Network Configuration", + "description": "The label for category Network Configuration in sidebar learn" + }, + "sidebar.learn.category.SDEX": { + "message": "SDEX", + "description": "The label for category SDEX in sidebar learn" + }, + "sidebar.learn.category.Migrate from Another Chain": { + "message": "Migrate from Another Chain", + "description": "The label for category Migrate from Another Chain in sidebar learn" + }, + "sidebar.learn.category.EVM Networks": { + "message": "EVM Networks", + "description": "The label for category EVM Networks in sidebar learn" + }, + "sidebar.learn.category.Interactive Learning": { + "message": "Interactive Learning", + "description": "The label for category Interactive Learning in sidebar learn" + }, + "sidebar.learn.category.Dapps Challenge": { + "message": "Dapps Challenge", + "description": "The label for category Dapps Challenge in sidebar learn" + }, + "sidebar.learn.link.Dapps Challenge Dashboard": { + "message": "Dapps Challenge Dashboard", + "description": "The label for link Dapps Challenge Dashboard in sidebar learn, linking to /docs/learn/interactive/dapps/dashboard" + }, + "sidebar.data_overview.doc.Soroban RPC": { + "message": "Soroban RPC", + "description": "The label for the doc item Soroban RPC in sidebar data_overview, linking to the doc data/rpc/README" + }, + "sidebar.data_overview.doc.Hubble": { + "message": "Hubble", + "description": "The label for the doc item Hubble in sidebar data_overview, linking to the doc data/hubble/README" + }, + "sidebar.data_overview.doc.Horizon": { + "message": "Horizon", + "description": "The label for the doc item Horizon in sidebar data_overview, linking to the doc data/horizon/README" + }, + "sidebar.tools.category.SDKs": { + "message": "SDKs", + "description": "The label for category SDKs in sidebar tools" + }, + "sidebar.tools.link.Anchor Platform": { + "message": "Anchor Platform", + "description": "The label for link Anchor Platform in sidebar tools, linking to /platforms/anchor-platform" + }, + "sidebar.tools.link.Stellar Disbursement Platform": { + "message": "Stellar Disbursement Platform", + "description": "The label for link Stellar Disbursement Platform in sidebar tools, linking to /platforms/stellar-disbursement-platform" + }, + "sidebar.validators.category.Admin Guide": { + "message": "Admin Guide", + "description": "The label for category Admin Guide in sidebar validators" + }, + "sidebar.horizon.category.Horizon": { + "message": "Horizon", + "description": "The label for category Horizon in sidebar horizon" + }, + "sidebar.horizon.category.Admin Guide": { + "message": "Admin Guide", + "description": "The label for category Admin Guide in sidebar horizon" + }, + "sidebar.horizon.category.API Reference": { + "message": "API Reference", + "description": "The label for category API Reference in sidebar horizon" + }, + "sidebar.horizon.category.Resources": { + "message": "Resources", + "description": "The label for category Resources in sidebar horizon" + }, + "sidebar.horizon.category.Accounts": { + "message": "Accounts", + "description": "The label for category Accounts in sidebar horizon" + }, + "sidebar.horizon.category.Assets": { + "message": "Assets", + "description": "The label for category Assets in sidebar horizon" + }, + "sidebar.horizon.category.Claimable Balances": { + "message": "Claimable Balances", + "description": "The label for category Claimable Balances in sidebar horizon" + }, + "sidebar.horizon.category.Effects": { + "message": "Effects", + "description": "The label for category Effects in sidebar horizon" + }, + "sidebar.horizon.category.Ledgers": { + "message": "Ledgers", + "description": "The label for category Ledgers in sidebar horizon" + }, + "sidebar.horizon.category.Liquidity Pools": { + "message": "Liquidity Pools", + "description": "The label for category Liquidity Pools in sidebar horizon" + }, + "sidebar.horizon.category.Offers": { + "message": "Offers", + "description": "The label for category Offers in sidebar horizon" + }, + "sidebar.horizon.category.Operations": { + "message": "Operations", + "description": "The label for category Operations in sidebar horizon" + }, + "sidebar.horizon.category.The Operation Object": { + "message": "The Operation Object", + "description": "The label for category The Operation Object in sidebar horizon" + }, + "sidebar.horizon.category.Payments": { + "message": "Payments", + "description": "The label for category Payments in sidebar horizon" + }, + "sidebar.horizon.category.Trades": { + "message": "Trades", + "description": "The label for category Trades in sidebar horizon" + }, + "sidebar.horizon.category.Transactions": { + "message": "Transactions", + "description": "The label for category Transactions in sidebar horizon" + }, + "sidebar.horizon.category.Structure": { + "message": "Structure", + "description": "The label for category Structure in sidebar horizon" + }, + "sidebar.horizon.category.Pagination": { + "message": "Pagination", + "description": "The label for category Pagination in sidebar horizon" + }, + "sidebar.horizon.category.Aggregations": { + "message": "Aggregations", + "description": "The label for category Aggregations in sidebar horizon" + }, + "sidebar.horizon.category.Order Books": { + "message": "Order Books", + "description": "The label for category Order Books in sidebar horizon" + }, + "sidebar.horizon.category.Paths": { + "message": "Paths", + "description": "The label for category Paths in sidebar horizon" + }, + "sidebar.horizon.category.Trade Aggregations": { + "message": "Trade Aggregations", + "description": "The label for category Trade Aggregations in sidebar horizon" + }, + "sidebar.horizon.category.Fee Stats": { + "message": "Fee Stats", + "description": "The label for category Fee Stats in sidebar horizon" + }, + "sidebar.horizon.category.Errors": { + "message": "Errors", + "description": "The label for category Errors in sidebar horizon" + }, + "sidebar.horizon.category.HTTP Status Codes": { + "message": "HTTP Status Codes", + "description": "The label for category HTTP Status Codes in sidebar horizon" + }, + "sidebar.horizon.category.Horizon-Specific Status Codes": { + "message": "Horizon-Specific Status Codes", + "description": "The label for category Horizon-Specific Status Codes in sidebar horizon" + }, + "sidebar.horizon.category.Result Codes": { + "message": "Result Codes", + "description": "The label for category Result Codes in sidebar horizon" + }, + "sidebar.horizon.category.Operation-Specific Result Codes": { + "message": "Operation-Specific Result Codes", + "description": "The label for category Operation-Specific Result Codes in sidebar horizon" + }, + "sidebar.hubble.category.Hubble": { + "message": "Hubble", + "description": "The label for category Hubble in sidebar hubble" + }, + "sidebar.hubble.category.Admin Guide": { + "message": "Admin Guide", + "description": "The label for category Admin Guide in sidebar hubble" + }, + "sidebar.hubble.category.Source System Ingestion": { + "message": "Source System Ingestion", + "description": "The label for category Source System Ingestion in sidebar hubble" + }, + "sidebar.hubble.category.Data Curation": { + "message": "Data Curation", + "description": "The label for category Data Curation in sidebar hubble" + }, + "sidebar.hubble.category.Visualization": { + "message": "Visualization", + "description": "The label for category Visualization in sidebar hubble" + }, + "sidebar.hubble.category.Scheduling and Orchestration": { + "message": "Scheduling and Orchestration", + "description": "The label for category Scheduling and Orchestration in sidebar hubble" + }, + "sidebar.hubble.category.Analyst Guide": { + "message": "Analyst Guide", + "description": "The label for category Analyst Guide in sidebar hubble" + }, + "sidebar.hubble.category.Data Catalog": { + "message": "Data Catalog", + "description": "The label for category Data Catalog in sidebar hubble" + }, + "sidebar.hubble.category.Data Dictionary": { + "message": "Data Dictionary", + "description": "The label for category Data Dictionary in sidebar hubble" + }, + "sidebar.soroban_rpc.category.Soroban RPC": { + "message": "Soroban RPC", + "description": "The label for category Soroban RPC in sidebar soroban_rpc" + }, + "sidebar.soroban_rpc.category.API Reference": { + "message": "API Reference", + "description": "The label for category API Reference in sidebar soroban_rpc" + }, + "sidebar.soroban_rpc.category.Methods": { + "message": "Methods", + "description": "The label for category Methods in sidebar soroban_rpc" + } +} diff --git a/i18n/es/docusaurus-plugin-content-docs/current/README.mdx b/i18n/es/docusaurus-plugin-content-docs/current/README.mdx new file mode 100644 index 000000000..bf0897cdb --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs/current/README.mdx @@ -0,0 +1,35 @@ +--- +title: Stellar Developer Docs +displayed_sidebar: build +hide_table_of_contents: true +--- + +## Navigating the docs + +### [Build](/docs/build/README.mdx) + +Contains tutorials and how-to guides for writing smart contracts, building applications, interacting with the network, and more. + +### [Learn](/docs/learn/fundamentals/README.mdx) + +Find all informational and conceptual content here. Learn about Stellar fundamentals like how accounts and transactions function, dive deeper into the functionality of each operation, discover how fees work, and more. + +### [Tokens](/docs/tokens/README.mdx) + +Information on how to issue assets on the Stellar network and create custom smart contract tokens. + +### [Data](/docs/data/README.mdx) + +Discover various data availability options: RPC, Hubble, and Horizon. + +### [Tools](/docs/tools/README.mdx) + +Learn about all the available tools at your disposal for building on, interacting with, or just watching the Stellar network. Also, find information on how to use the Anchor Platform or Stellar Disbursement Platform. + +### [Networks](/docs/networks/README.mdx) + +Information about deployed networks (Mainnet, Testnet, and Futurenet), current software versions, and resource limitations and fees. + +### [Validators](/docs/validators/README.mdx) + +Everything you'll need to know if you want to run, operate, and maintain a core validator node on the Stellar network. diff --git a/i18n/es/docusaurus-plugin-content-docs/current/build/README.mdx b/i18n/es/docusaurus-plugin-content-docs/current/build/README.mdx new file mode 100644 index 000000000..f4470672f --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs/current/build/README.mdx @@ -0,0 +1,35 @@ +--- +title: Introduction +sidebar_position: 0 +hide_table_of_contents: true +--- + +This a new change again + +The Build section is split into three parts: 1) writing smart contracts, 2) building applications, and 3) how-to guides. + +Find explanations on what each section contains below. + +## Smart contracts + +Smart contracts are self-executing programs with the terms of an agreement written directly into the code. They automatically enforce and execute the terms of the contract when predefined conditions are met. Developers must define the rules and logic of the contract while also ensuring security. Once written and tested, smart contracts are deployed to the blockchain, where they become immutable and publicly accessible. + +This section will walk you through how to get set up to write smart contracts on Stellar, plus an introduction to testing, storing data, and deploying your contracts. It also provides an array of example contracts for use. + +## Applications + +Applications interact with the blockchain and can use smart contracts as the backend. They provide user interfaces, manage user interactions, and can integrate with smart contracts to operate. Users can interact with the blockchain using the application interface. Writing smart contracts focuses on the backend logic and rules enforced on the blockchain while building applications involves creating the front end and integrating it with these smart contracts to provide a complete user experience. + +:::note + +You can create applications on Stellar without using smart contracts, as demonstrated in the [Wallet SDK tutorial](./apps/wallet/overview.mdx) or the [JS SDK Payment Application tutorial](./apps/example-application-tutorial/overview.mdx). + +::: + +This section walks you through design considerations for applications and tutorials for building applications with or without smart contracts. + +## How-To Guides + +This section provides step-by-step instructions to help users complete specific tasks associated with developing on Stellar. These tasks can include instructions for aspects of writing contracts, interacting with contracts, building applications, using Stellar operations, setting up infrastructure, and more. + +How-to guides assume that the user has some experience and knowledge with building on Stellar and are not typically for beginners. diff --git a/i18n/es/docusaurus-plugin-content-docs/current/build/apps/README.mdx b/i18n/es/docusaurus-plugin-content-docs/current/build/apps/README.mdx new file mode 100644 index 000000000..552fe5d9c --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs/current/build/apps/README.mdx @@ -0,0 +1,10 @@ +--- +title: Build Applications +sidebar_position: 30 +--- + +import DocCardList from "@theme/DocCardList"; + +This section walks you through design considerations for applications and tutorials for building applications with or without smart contracts. + + diff --git a/i18n/es/docusaurus-plugin-content-docs/current/build/apps/application-design-considerations.mdx b/i18n/es/docusaurus-plugin-content-docs/current/build/apps/application-design-considerations.mdx new file mode 100644 index 000000000..2ccedc965 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs/current/build/apps/application-design-considerations.mdx @@ -0,0 +1,110 @@ +--- +title: Application Design Considerations +sidebar_position: 10 +--- + +## Custody models + +When building an application, one of the first things you have to decide is how your users’ secret keys will be secured and stored. Stellar applications give users access to their accounts that are stored on the ledger, and access to these accounts is controlled by the account’s secret key. That secret key proves that the user has custody or β€œowns” the account. + +There are four custody options to consider: + +- Non-custodial service - the user of the application stores their own secret key +- Custodial service - the service provider (application) stores the users’ secret keys +- Mixture of both - with the use of [multisig](../../learn/encyclopedia/security/signatures-multisig.mdx), this option is useful for maintaining non-custodial status while still allowing for account recovery +- Third-party key management services - integrate a third-party custodial service into your application that can store your users’ secret keys + +### Non-custodial service + +In a non-custodial service, the user of the application stores the secret key for their account and permissions the application to send requests to delegate transaction signing. There are some potential usability issues as the user has to know how to securely store their own account credentials and safely navigate transaction signing on their end. If they lose their secret key, they will also lose access to their account. + +Typically, non-custodial applications create or import a pre-existing Stellar account for each user. + +### Custodial service + +With a custodial service, the service provider (an application such as a centralized exchange) stores the users’ secret keys and delegates usage rights to the user. + +Many custodial services choose to use a single pooled Stellar account (called shared, omnibus, or [pooled accounts](../../learn/encyclopedia/transactions-specialized/pooled-accounts-muxed-accounts-memos.mdx)) to handle transactions on behalf of their users instead of creating a new Stellar account for each user. To distinguish between individual users in a pooled account, we encourage the implementation of [muxed accounts](../../learn/encyclopedia/transactions-specialized/pooled-accounts-muxed-accounts-memos.mdx#muxed-accounts). + +### A mixture of non-custodial and custodial + +Building an application with [multi-signature](../../learn/encyclopedia/security/signatures-multisig.mdx) capabilities allows you to have a non-custodial service with account recovery. If the user loses their secret key, they can still sign transactions with other authorized signatures, granted the signature threshold is high enough. + +### Third-party key management services​ + +There are several apps and services that specialize in adding additional security layers to users' accounts. Check them out if you're interested in integrating a third-party key management service: + +- [StellarAuth](https://stellarauth.com/) +- [Ledger](https://www.ledger.com/) +- [Trezor](https://trezor.io/) +- [StellarGuard](https://stellarguard.me/) +- [LobstrVault](https://vault.lobstr.co/) + +## Application security + +Even though wallets can operate client-side, they deal with a user’s secret keys, which give direct access to their account, and to any value they hold. That’s why it’s essential to require all web traffic to flow over strong TLS methods. Even when developing locally, use a non-signed localhost certificate to develop secure habits from the very beginning. Stellar is a powerful money-moving software β€” don’t skimp on security. + +For more information, check out our guide to [securing web-based products](https://www.stellar.org/developers/guides/walkthroughs/securing-web-projects.html). + +## Wallet services + +A wallet typically has these basic functions: key storage, account creation, transaction signing, and queries to the Stellar database. There are some services that take care of all of these functions for you, so you can build whatever you’d like around it. Check out some of these wallet services below. + +- [Albedo](https://albedo.link/) +- [Freighter](https://www.freighter.app/) + +## Account creation strategies + +In this section, we will go over the new user account creation flow between non-custodial wallets and anchors with SEP-24 and/or SEP-6 implementations. A Stellar account is created with a keypair (a public key and private key) and the minimum balance of XLM. + +When a new customer downloads the wallet application and goes through the deposit flow for the first time, their Stellar account can be created by either the user’s wallet application or the anchor facilitating the first deposit. This section describes each of these strategies. + +### Option 1: The anchor creates and funds the Stellar account​ + +For this option, the wallet needs to allow users to initiate their first deposit without having to add an asset/establish a trustline. The wallet then prompts the user to add the trustline once funds are received by the anchor. The flow looks like this: + +1. The wallet registers a new user and issues a keypair. +2. The wallet initiates the first deposit on behalf of the user without requiring the user to add the asset/create the trustline. +3. The anchor provides deposit instructions to the customer. +4. The user transfers money from a bank account to the anchor’s bank account. +5. Once the anchor receives the transfer, the anchor creates and funds the Stellar account for the customer. +6. The wallet detects that the account has been created and a trustline must be established. +7. The wallet prompts the user to add the asset/create the trustline. +8. Finally, the anchor sends the deposit funds to the user’s Stellar account. + +:::info + +An anchor should always maintain a healthy amount of XLM in its distribution account to support new account creations. If doing so becomes unsustainable, it’s recommended that the anchor collaborates with wallets to determine a strategy based on the number of account creation requests. The recommended amount is 2XLM per user account creation (1XLM to meet the minimum balance requirement, and 1XLM for establishing trustlines and covering transaction fees). + +::: + +With the flow described above, the wallet and the anchor have to facilitate listening for and responding to the trustline status, which can create user experience frictions when waiting for the trustline to be established. To address this issue, Protocol 15 introduced claimable balances, which enhance the flow by allowing users to start using the wallet without having to secure XLM. Both the wallet and the anchor have to implement claimable balance support in order to make this flow work. + +The flow with Claimable Balances looks like this: + +1. The wallet registers a new user, and generates a keypair. +2. The wallet initiates a deposit on behalf of a user. +3. The anchor provides deposit instructions to the wallet. +4. The user transfers money from a bank account to the anchor’s account. +5. The anchor creates and funds the user's Stellar account plus the amount required for trustlines and transaction fees. Again, we suggest 2 XLM to start. +6. The anchor creates a Claimable Balance. +7. The wallet detects the Claimable Balance for the account, claims the funds, and posts it in the wallet. + +### Option 2: the wallet creates and funds the Stellar account upon user sign-up​ + +For this option, the wallet creates and funds the Stellar account upon every new user sign-up with the minimum requirement of 1XLM, plus the .5XLM reserve for establishing the first trustline, plus a bit more to cover transaction fees. For more information on minimum balances, check out the [Lumens section](../../learn/fundamentals/lumens.mdx#minimum-balance). + +The flow looks like this: + +1. Upon a new user signup, the wallet issues a keypair, then creates and funds the user's Stellar account with 2XLM. +2. Then the wallet creates a trustline, and initiates the first deposit. +3. Once the deposit request is sent to the anchor, the anchor provides instructions for the deposit. +4. The customer transfer funds from a personal bank account to the anchor’s account. +5. The anchor receives the funds, then sends them to the user’s Stellar account. +6. The wallet detects that funds were sent and notifies the user. + +:::note + +In the examples above, we suggest having the anchor or wallet cover minimum balance and trustline XLM requirements by depositing funds directly into a user's account. We made that suggestion for the sake of simplicity, but in all cases, the anchor or wallet could instead use sponsored reserves to ensure that when a user closes a trustline or merges their account, the reserve reverts to the sponsoring account rather than to the user's account. + +::: diff --git a/i18n/es/docusaurus-plugin-content-docs/current/build/apps/dapp-frontend.mdx b/i18n/es/docusaurus-plugin-content-docs/current/build/apps/dapp-frontend.mdx new file mode 100644 index 000000000..3181054a8 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs/current/build/apps/dapp-frontend.mdx @@ -0,0 +1,444 @@ +--- +sidebar_position: 70 +title: Build a Dapp Frontend +description: Make a frontend web app that interacts with your smart contracts. +pagination_prev: build/smart-contracts/getting-started/deploy-increment-contract +--- + +This is a continuation of the [Getting Started tutorial](../smart-contracts/getting-started/README.mdx), where you should have deployed two smart contracts to the public network. In this section, we'll create a web app that interacts with the contracts via RPC calls. + +Let's get started. + +## Initialize a frontend toolchain + +You can build a Soroban app with any frontend toolchain or integrate it into any existing full-stack app. For this tutorial, we're going to use [Astro](https://astro.build/). Astro works with React, Vue, Svelte, any other UI library, or no UI library at all. In this tutorial, we're not using a UI library. The Soroban-specific parts of this tutorial will be similar no matter what frontend toolchain you use. + +If you're new to frontend, don't worry. We won't go too deep. But it will be useful for you to see and experience the frontend development process used by Soroban apps. We'll cover the relevant bits of JavaScript and Astro, but teaching all of frontend development and Astro is beyond the scope of this tutorial. + +Let's get started. + +You're going to need [Node.js](https://nodejs.org/en/download/package-manager/) v18.14.1 or greater. If you haven't yet, install it now. + +We want to initialize our current project as an Astro project. To do this, we can again turn to the `stellar contract init` command, which has a `--frontend-template` flag that allows us to pass the url of a frontend template repository. As we learned in [Storing Data](../smart-contracts/getting-started/storing-data.mdx#adding-the-increment-contract), `stellar contract init` will not overwrite existing files, and is safe to use to add to an existing project. + +From our `soroban-hello-world` directory, run the following command to add the Astro template files. + +```sh +stellar contract init ./ \ + --frontend-template https://github.com/stellar/soroban-astro-template +``` + +This will add the following to your project, which we'll go over in more detail below. + +```bash +β”œβ”€β”€ CONTRIBUTING.md +β”œβ”€β”€ initialize.js +β”œβ”€β”€ package-lock.json +β”œβ”€β”€ package.json +β”œβ”€β”€ packages +β”œβ”€β”€ public +β”‚Β Β  └── favicon.svg +β”œβ”€β”€ src +β”‚Β Β  β”œβ”€β”€ components +β”‚Β Β  β”‚Β Β  └── Card.astro +β”‚Β Β  β”œβ”€β”€ env.d.ts +β”‚Β Β  β”œβ”€β”€ layouts +β”‚Β Β  β”‚Β Β  └── Layout.astro +β”‚Β Β  └── pages +β”‚Β Β  └── index.astro +└── tsconfig.json +``` + +## Generate an NPM package for the Hello World contract + +Before we open the new frontend files, let's generate an NPM package for the Hello World contract. This is our suggested way to interact with contracts from frontends. These generated libraries work with any JavaScript project (not a specific UI like React), and make it easy to work with some of the trickiest bits of Soroban, like encoding [XDR](../../learn/encyclopedia/contract-development/types/fully-typed-contracts.mdx). + +This is going to use the CLI command `stellar contract bindings typescript`: + +```bash +stellar contract bindings typescript \ + --network testnet \ + --contract-id $(cat .stellar/contract-ids/hello_world.txt) \ + --output-dir packages/hello_world +``` + +This project is set up as an NPM Workspace, and so the `hello_world` client library was generated in the `packages` directory at `packages/hello_world`. + +We attempt to keep the code in these generated libraries readable, so go ahead and look around. Open up the new `packages/hello_world` directory in your editor. If you've built or contributed to Node projects, it will all look familiar. You'll see a `package.json` file, a `src` directory, a `tsconfig.json`, and even a README. + +## Generate an NPM package for the Increment contract + +Though we can run `soroban contract bindings typescript` for each of our contracts individually, the [soroban-astro-template](https://github.com/stellar/soroban-astro-template) that we used as our template includes a very handy `initialize.js` script that will handle this for all of the contracts in our `contracts` directory. + +In addition to generating the NPM packages, `initialize.js` will also: + +- Generate and fund our Stellar account +- Build all of the contracts in the `contracts` dir +- Deploy our contracts +- Create handy contract clients for each contract + +We have already taken care of the first three bullet points in earlier steps of this tutorial, so those tasks will be noops when we run `initialize.js`. + +### Configure initialize.js + +We need to make sure that `initialize.js` has all of the environment variables it needs before we do anything else. Copy the `.env.example` file over to `.env`. The environment variables set in `.env` are used by the `initialize.js` script. + +```bash +cp .env.example .env +``` + +Let's take a look at the contents of the `.env` file: + +``` +# Prefix with "PUBLIC_" to make available in Astro frontend files +PUBLIC_SOROBAN_NETWORK_PASSPHRASE="Standalone Network ; February 2017" +PUBLIC_SOROBAN_RPC_URL="http://localhost:8000/soroban/rpc" + +SOROBAN_ACCOUNT="me" +SOROBAN_NETWORK="standalone" + +# env vars that begin with PUBLIC_ will be available to the client +PUBLIC_SOROBAN_RPC_URL=$SOROBAN_RPC_URL +``` + +This `.env` file defaults to connecting to a locally running network, but we want to configure our project to communicate with Testnet, since that is where we deployed our contracts. To do that, let's update the `.env` file to look like this: + +```diff +# Prefix with "PUBLIC_" to make available in Astro frontend files +-PUBLIC_SOROBAN_NETWORK_PASSPHRASE="Standalone Network ; February 2017" ++PUBLIC_SOROBAN_NETWORK_PASSPHRASE="Test SDF Network ; September 2015" +-PUBLIC_SOROBAN_RPC_URL="http://localhost:8000/soroban/rpc" ++PUBLIC_SOROBAN_RPC_URL="https://soroban-testnet.stellar.org:443" + +-SOROBAN_ACCOUNT="me" ++SOROBAN_ACCOUNT="alice" +-SOROBAN_NETWORK="standalone" ++SOROBAN_NETWORK="testnet" +``` + +:::info + +This `.env` file is used in the `initialize.js` script. When using the CLI, we can still use the network configuration we set up in the [Setup](../smart-contracts/getting-started/setup.mdx) step, or by passing the `--rpc-url` and `--network-passphrase` flags. + +::: + +### Run `initialize.js` + +First let's install the Javascript dependencies: + +```bash +npm install +``` + +And then let's run `initialize.js`: + +```bash +npm run init +``` + +As mentioned above, this script attempts to build and deploy our contracts, which we have already done. The script is smart enough to check if a step has already been taken care of, and is a no-op in that case, so it is safe to run more than once. + +### Call the contract from the frontend + +Now let's open up `src/pages/index.astro` and take a look at how the frontend code integrates with the NPM package we created for our contracts. + +Here we can see that we're importing our generated `helloWorld` client from `../contracts/hello_world`. We're then invoking the `hello` method and adding the result to the page. + +```ts title="src/pages/index.astro" +--- +import Layout from "../layouts/Layout.astro"; +import Card from "../components/Card.astro"; +import helloWorld from "../contracts/hello_world"; +const { result } = await helloWorld.hello({ to: "you" }); +const greeting = result.join(" "); +--- + + ... + +

{greeting}

+``` + +Let's see it in action! Start the dev server: + +```bash +npm run dev +``` + +And open in your browser. You should see the greeting from the contract! + +You can try updating the `{ to: 'Soroban' }` argument. When you save the file, the page will automatically update. + +:::info + +When you start up the dev server with `npm run dev`, you will see similar output in your terminal as when you ran `npm run init`. This is because the `dev` script in package.json is set up to run `npm run init` and `astro dev`, so that you can ensure that your deployed contract and your generated NPM pacakage are always in sync. If you want to just start the dev server without the initialize.js script, you can run `npm run astro dev`. + +::: + +### What's happening here? + +If you inspect the page (right-click, inspect) and refresh, you'll see a couple interesting things: + +- The "Network" tab shows that there are no Fetch/XHR requests made. But RPC calls happen via Fetch/XHR! So how is the frontend calling the contract? +- There's no JavaScript on the page. But we just wrote some JavaScript! How is it working? + +This is part of Astro's philosophy: the frontend should ship with as few assets as possible. Preferably zero JavaScript. When you put JavaScript in the [frontmatter](https://docs.astro.build/en/core-concepts/astro-components/), Astro will run it at build time, and then replace anything in the `{...}` curly brackets with the output. + +When using the development server with `npm run dev`, it runs the frontmatter code on the server, and injects the resulting values into the page on the client. + +You can try building to see this more dramatically: + +```bash +npm run build +``` + +Then check the `dist` folder. You'll see that it built an HTML and CSS file, but no JavaScript. And if you look at the HTML file, you'll see a static "Hello Soroban" in the `

`. + +During the build, Astro made a single call to your contract, then injected the static result into the page. This is great for contract methods that don't change, but probably won't work for most contract methods. Let's integrate with the `incrementor` contract to see how to handle interactive methods in Astro. --> + +## Call the incrementor contract from the frontend + +While `hello` is a simple view-only/read method, `increment` changes on-chain state. This means that someone needs to sign the transaction. So we'll need to add transaction-signing capabilities to the frontend. + +The way signing works in a browser is with a _wallet_. Wallets can be web apps, browser extensions, standalone apps, or even separate hardware devices. + +### Install Freighter Extension + +Right now, the wallet that best supports Soroban is [Freighter](../guides/freighter/README.mdx). It is available as a Firefox Add-on, as well as extensions for Chrome and Brave. Go ahead and [install it now](https://freighter.app). + +Once it's installed, open it up by clicking the extension icon. If this is your first time using Freighter, you will need to create a new wallet. Go through the prompts to create a password and save your recovery passphrase. + +Go to Settings (the gear icon) β†’ Preferences and toggle the switch to Enable Experimental Mode. Then go back to its home screen and select "Test Net" from the top-right dropdown. Finally, if it shows the message that your Stellar address is not funded, go ahead and click the "Fund with Friendbot" button. + +Now you're all set up to use Freighter as a user, and you can add it to your app. + +### Add Freighter + +We're going to add a "Connect" button to the page that opens Freighter and prompts the user to give your web page permission to use Freighter. Once they grant this permission, the "Connect" button will be replaced with a message saying, "Signed in as [their public key]". + +First, add [@stellar/freighter-api](https://www.npmjs.com/package/@stellar/freighter-api) as a dependency: + +```bash +npm install @stellar/freighter-api +``` + +Now let's add a new component to the `src/components` directory called `ConnectFreighter.astro` with the following contents: + +```html title="src/components/ConnectFreighter.astro" +
+
+ +
+
+ + + + +``` + +Some of this may look surprising. `