init (#1)

Author: jesmarsc

.eslintignore

@@ -0,0 +1,10 @@
+dist
+node_modules
+docs
+.github
+build
+/*.js
+/*.ts
+/*.d.ts
+static
+.docusaurus

.eslintrc.js

@@ -0,0 +1,6 @@
+module.exports = {
+  extends: ["@stellar/eslint-config"],
+  rules: {
+    "import/no-unresolved": 0,
+  },
+};

.github/workflows/main.yml

@@ -0,0 +1,32 @@
+name: Format MDX and Lint
+
+on:
+  pull_request:
+    branches:    
+      - main
+
+  workflow_dispatch:
+
+jobs:
+  build:
+    runs-on: ubuntu-latest
+
+    steps:
+      - name: Checkout App Repo
+        uses: actions/checkout@v3
+
+      - name: Setup Node
+        uses: actions/setup-node@v3
+        with:
+          node-version: '16'
+          cache: 'yarn'
+          cache-dependency-path: '**/yarn.lock'
+
+      - name: Install App Dependencies
+        run: yarn --prefer-offline
+
+      - name: Format MDX with Prettier
+        run: yarn check:mdx
+
+      - name: Lint with ESLint
+        run: yarn lint:fix

.gitignore

@@ -0,0 +1,20 @@
+# Dependencies
+node_modules
+
+# Production
+/build
+
+# Generated files
+.docusaurus
+.cache-loader
+
+# Misc
+.DS_Store
+.env.local
+.env.development.local
+.env.test.local
+.env.production.local
+
+npm-debug.log*
+yarn-debug.log*
+yarn-error.log*

.prettierrc.js

@@ -0,0 +1,13 @@
+module.exports = {
+  ...require("@stellar/prettier-config"),
+  // This is mostly content, and prose wrap has a way of exploding markdown
+  // diffs. Override the default for a better experience.
+  overrides: [
+    {
+      files: "*.mdx",
+      options: {
+        proseWrap: "never",
+      },
+    },
+  ],
+};

babel.config.js

@@ -0,0 +1,3 @@
+module.exports = {
+  presets: [require.resolve('@docusaurus/core/lib/babel/preset')],
+};

docs/anchoring-assets/enabling-cross-border-payments/index.mdx

@@ -0,0 +1,49 @@
+---
+title: Overview
+order: 10
+---
+
+import { Alert } from "@site/src/components/Alert";
+
+Supporting cross-border payments of an asset through the Stellar network requires cooperation between a sending anchor (**SA**) and receiving anchor (**RA**). In this section, we'll only go over the steps necessary for building a SEP-31 receiving anchor, but documentation for building a sending anchor is in development.
+
+Specifically, we will go over the SDF's [Tools and References](./reference-implementations.mdx) as well as all three stages of the development process:
+
+1. [Setting up a test server](./setting-up-test-server.mdx)
+1. [Setting up a production server](./setting-up-production-server.mdx)
+1. [Launching](./launch.mdx)
+
+## The Basic User Experience
+
+Unlike with SEP-24, SEP-31 involves a sending user (**SU**) and receiving user (**RU**), so both users' experience is described [here](../../anchoring-assets/enabling-cross-border-payments/setting-up-test-server/#stellar-docsearch-form).
+
+<Alert>
+
+Note: **SA**'s are not necessarily wallet applications. This means the **SU** may not interact with a mobile application, but could go to a website or physical remittance location instead. Obviously, this affects the **SU** experience.
+
+</Alert>
+
+Generally, the experience of the SU and RU would look something like this:
+
+1. The **SU** opens an app, website, or goes to a physical remittance location
+1. The **SU** specifies the asset and amount to send, and the asset that should be received
+1. The **SA** finds the appropriate **RA** for the asset, authenticates with the **RA**, and parses the **RA**'s requirements for sending payments
+1. The **SA** collects both the **SU** and **RU** KYC information requested by the **RA** from the **SU**, as well as the transaction information
+   - **RU**'s should not have to take any action to receive a cross-border payment
+   - However, it is possible to require action from the **RU** if absolutely necessary
+1. The **SA** registers the **RU** and potentially **SU** with the **RA** via [SEP-12](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0012.md)
+1. Once the **RA** is ready to receive the payment, the **SA** makes the Stellar path payment to the **RA** using the **SU** and **RU** assets
+1. Once the **RA** receives the path payment, it attempts make the associated off-chain transfer (usually bank transfer) using the KYC and transaction information sent by the **SA**
+1. If the transfer to the **RU** fails, the **SU** will be notified by the **SA** to update the invalid or missing fields, and the **RA** will retry once the **SA** sends the updated info.
+
+The **RU** should then receive the funds sent by the **SA** once the **RA** has the necessary to make the final transfer.
+
+<Alert>
+
+Note: The final off-chain transfer by the **RA** may not be a bank transfer. For example, the destination could be a mobile money account managed by the **RA**. The methods used to transfer the payment off-chain to the **RU** is up to the **RA**, and **SA**s should be aware of the off-chain transfer methods of their partner **RA**s.
+
+</Alert>
+
+## Interoperability and Stellar Ecosystem Proposals
+
+As mentioned, this section will outline how to implement a [SEP-31](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0031.md) receiver, but these servers require [SEP-1](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0001.md), [10](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0010.md), and [12](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0012.md) to be implemented as well. SEP-1 is described in [this guide](../../issuing-assets/publishing-asset-info.mdx), and SEP-10 & 12 are described [here](../../anchoring-assets/enabling-cross-border-payments/setting-up-test-server.mdx#authentication).

docs/anchoring-assets/enabling-cross-border-payments/launch.mdx

@@ -0,0 +1,49 @@
+---
+title: Launch
+order: 50
+---
+
+Once the testnet and mainnet servers are deployed, KYC collection conforms to regulations, banking rails are integrated, and the whole system is audited, it's time to prepare for launch.
+
+## Market Making
+
+It is critical for an anchored asset to have liquid trading markets with XLM and ideally partner **SA** assets. Without a deep orderbook, its impossible to facilitate path payments at rates competivtive with equivalent off-chain fiat assets.
+
+The SDF maintains a trading bot called [Kelp](https://kelpbot.io/) that supports many trading and market making strategies out of the box, all of which are described in [Kelp's Github Repo](https://github.com/stellar/kelp#kelp). You can use Kelp for free and start automating the order placement process in a matter of minutes.
+
+Once the order placement is automatic, you should track the health of your token's market with these two parameters:
+
+- Bid/Ask Amounts: Both sides of the order book should have at least 25k USD
+- Spread Size: The average price of the bids and asks should be within 4% of each other.
+
+The 25k USD value is relative to a new anchor that is still developing its business. Once the volume of traded assets (and the total supply) grows, this value should be increased.
+
+## Creating an Anchor Website
+
+A website allows wallets and consumers to find information about your team and your business, get in contact with questions and feedback, and understand how your service works. Your issuing account should link to that website so there's a clear connection between the Stellar asset and the URL. To do that, usee the `set options`, and choose the URL as the home domain. You can find more information about how that process works [in our guide to publishing asset information](../../issuing-assets/publishing-asset-info.mdx).
+
+Here is a list of requirements to make sure users have a great experience navigating through your website:
+
+### Branding Visuals
+
+Users should feel that they are in the company's domain based on the branding of the webpage. The brand universe can include many aspects, such as: company logo or symbol, slogan, colors, fonts, icons, etc...
+
+### Company Description
+
+Users want to know who you are and what you do before they'll trust your service or hold your asset. Your website should describe your business, clarify your mission, and outline your vision. Giving more information about your company's executive team, or about your team in general, is a great way to increase users' confidence, and conversions.
+
+Describing how are you integrated with the Stellar Network (and with which wallets) is also a great way to show users that the system is reliable, and that it conforms to the best protocols and practices of the financial industry.
+
+Finally, make sure to describe what your asset represents, how it's backed (e.g. it's 1:1 with a fiat reserve), how users can redeem it, and who can use it (anyone, just for retail, etc).
+
+### Customer Support
+
+Your webpage is also where users will go to report problems and reach out with questions and feedback. Make sure you clearly describe the process for contacting you, and for reporting bugs, and have a plan in place to offer necessary support.Adding a FAQ section once is a great way to defray support tickets and get information to users faster.
+
+You should also have a contact email so customers can get in touch, report inconsistencies, and open tickets. Once you get those tickets, you need to answer them in a reasonable amount of time.
+
+## Connecting to Sending Anchors
+
+All **RA**s must connect with **SA**s that have transaction volume to send. The SDF works with strategic partners to build and improve these relationships, and the ultimate goal is for there to be an entire ecosystem (or network) of **SA**s and **RA**s globally.
+
+Stellar.org does not yet host any resources documenting existing SEP-31 anchors, but it is coming.

docs/anchoring-assets/enabling-cross-border-payments/metadata.json

@@ -0,0 +1,4 @@
+{
+  "title": "Enable Cross-border Payments",
+  "order": 30
+}

docs/anchoring-assets/enabling-cross-border-payments/reference-implementations.mdx

@@ -0,0 +1,34 @@
+---
+title: Tools and References
+order: 20
+---
+
+These docs walk through the steps necessary to set up and launch both a test server and a production server for SEP-31 cross-border payments, but before you get any deeper, it's worth noting: you don't have to start from scratch. SDF offers some tools that make it easy to implement those servers, and test them from the sending anchor (**SA**) side.
+
+## Anchor Server Reference Implementation
+
+To help with server setup, SDF created [Polaris](https://github.com/stellar/django-polaris), an extendable django reusable-app that comes with fully-implemented endpoints, templates, and database models. It's built in Python using the community-supported [Stellar Python SDK](https://github.com/StellarCN/py-stellar-base), and is compliant with the Stellar Ecosystem Protocols mentioned in the previous section.
+
+TODO: REPLACE PNG ![Screenshots of the reference implementation](../../web-assets/polaris.png)
+
+Polaris modularizes the parts of the codebase that interface with the Stellar network, and provides clear methods for developers to integrate their own customer registrations, banking connections, and KYC and transcation processing. That means you can focus on implementing the business- and country-related aspects of your product without having to spend much time defining how to connect the server to the Stellar Network.
+
+If you choose to use Polaris, you can jumpstart your deployment, and connect local rails to Stellar in weeks instead of months.
+
+## Demo Client & Deployed Example
+
+Once you have a server set up, SDF also maintains a [Demo Wallet Project](https://demo-wallet.stellar.org/) that makes it easy to test your implementation on both the testnet and the pubnet.
+
+This allows you to run through your receiving anchor's flow by entering information to a fake wallet application like a real sending user would.
+
+![Screenshot of the demo client](../../web-assets/demo-wallet-sep31.png)
+
+With the demo client, you can test your payment flows, and get information about the transactions that are created during those processes. It gives a clear step-by-step visual example of how the functionalities work along with insightful information about the requests, protocols, and possible validation messages. To start testing the deploys, simply update the settings of the Demo Client (click the gear button on the bottom right) to include your project's information.
+
+## Anchor Validation Suite
+
+The Anchor Validation Suite is a set of tests that helps confirming if your anchor implementation is compliant with the latest specifications of the SEP-31 standard. This is a great resource for people that are getting started building an anchor and want to check what's still missing in their implementation, or for teams that have already finalized the anchor development and want an extra validation on the codebase. Also, the Anchor Validation Suite doesn't replace the necessity of having a professional security auditor reviewing the whole project.
+
+TODO: REPLACE PNG ![Screenshot of the Anchor Validation Suite's UI](../../web-assets/anchor-validation-suite.png)
+
+The Anchor Validation Suite codebase is available in an open-sourced [Github Repository](https://github.com/stellar/transfer-server-validator/), where you can check in details exactly how all tests work. SDF also maintains a [deployed version of the Validation Suite](http://anchor-validator.stellar.org/) with a UI for running the tests without the need to setup your own infrastructure. In order to also test the interactive parts of SEP-24, you'll need to add test values to all the required interactive flow fields. The [Github Repository Readme file](https://github.com/stellar/transfer-server-validator/#providing-field-values) has more information on how exactly those fields need to be added. Finally, you can also trigger the tests directly from a Continuous Integration tool (like CircleCI or Jenkins), in order to have continuous monitoring of your anchor infrastructure.