stellar.toml file information already, we can use that to display some interactive elements to the user.
Prompt for authentication
The
/src/routes/dashboard/transfers/+page.svelte is doing a lot of work throughout these sections, and we are chopping it up in various ways for display as part of this tutorial. For a full picture of this file, please remember to check the source code./src/routes/dashboard/transfers/+page.svelte
Requesting a challenge transaction
Now, when the user clicks the “authenticate” button, it triggers theauth function.

/src/routes/dashboard/transfers/+page.svelte
auth function, BasicPay makes a GET request with an account param (the public key of the user) to the anchor, which sends back a Stellar transaction signed by the server’s signing key (called a challenge transaction) with an invalid sequence number so it couldn’t actually do anything if it were accidentally submitted to the network.
/src/lib/stellar/sep10.js
Sign and submit the challenge transaction
In response, the user signs the transaction. You may have noticed we present this challenge transaction to the user with our regular confirmation modal. Once they’ve signed the transaction, the application sends it back to the anchor with aPOST request. If the signature checks out, the success response will contain a JSON Web Token (JWT), which BasicPay stores in the webAuthStore store to use for future interactions with the anchor.
/src/routes/dashboard/transfers/+page.svelte
submitChallengeTransaction function is quite simple. We take the transaction (in XDR format) and the domain name, and submit it to the relevant WEB_AUTH_ENDPOINT provided by the home domain’s stellar.toml file.
/src/lib/stellar/sep10.js
About the webAuthStore store
Like so much of our BasicPay application, the various authentication tokens the user may have accumulated over time are stored in the browser’s localStorage. There’s not much special about this particular store, but here’s how we put it together:
/src/lib/stores/webAuthStore.js
