Add support for offramping BRLA digital token

[ebma]

Context

The BRLA digital token can be used to on/offramp tokens to Brazil. Thus, offramping support to Brazil using the BRLA token is a great addition to Vortex.

TODO

Add logic for creating a user subaccount and do KYC

This ticket is for the logic. Assume that all the data depicted here is collected in the KYC UI and available to the functions implemented as part of this ticket.

On the signer-service:

• Implement a function that receives a tax ID and returns whether the user exists and is KYC'd or not. This function should return the following items of the subaccount query: id, kyc.level, wallets.evm, as well as the 'failure reason' of the KYC if anything was received from the webhook endpoint, see below. The kyc.level can be used to check if the user is KYC'd.
• Implement a function that can create a subaccount and return the ID
• Implement a function that can monitor the KYC process.
  • The KYC events are emitted in Webhooks. We need to create a new POST endpoint on the signer-service. This endpoint needs to be registered as a webhook on the BRLA API when the signer-service starts. The data contained in the KYC webhook events includes the id and taxId of the user. It's probably best if the signer-service continuously listens to all these events and keeps an internal in-memory store of the KYC status of all the users (taxIds) that are received. The failureReason that is emitted in case the KYC failed should also be made available. The Webhook Events are the only way to access the failure reason.

The signer-service should expose the first two functions via endpoints. The monitoring of the KYC process doesn't need to be exposed. It should only be used internally to monitor the events and catch the failure reasons, if any. The frontend can poll the KYC status of the user and doesn't need to subscribe.

Open questions

• We can query the subaccounts. The response contains a kyc object with a level. What does this level indicate and which levels are available?

Add logic for the ramping

Assume the offramp process only starts for already-KYC'd users.

The flow can stay the same for both AssetHub and EVM-based offramps up until the 'subsidizePostSwap' phase. Afterwards, Vortex shouldn't use Spacewalk to redeem the funds to Stellar but back to Moonbeam.

• Implement a new phase 'executePendulumToMoonbeamXCM'.
  • Transfers the BRLA received from the Nabla Swap to the evm address that is included in the user's subaccount data on Moonbeam.
  • Wait until the tokens are received on Moonbeam
• Rename 'executeMoonbeamXCM' to 'executeMoonbeamToPendulumXCM' and rename 'executeAssetHubXCM' to 'executeAssetHubToPendulumXCM'
• Implement a new phase 'performBrlaPayoutOnMoonbeam'
  • Calls the payout endpoint to create a pay-out order of the tokens on behalf of the user. The destination should be a pix key that is collected on the swap page and put on the OfframpState so it's available here.
  • Wait for the payout order receipt before navigating to the 'success' page

For the brazil offramp, we don't need to bother with Stellar ephemeral accounts. We also don't need to have an ephemeral on Moonbeam. So one less thing to worry about.

Notes

Keep in mind that on-ramping support from Brazil to a target chain (EVM/AssetHub) is also supposed to happen soon. Thus, try to make the implementation such that it's not tailored only for the offramp scenario but generic enough to allow adding the onramping easily.
Also, this logic will get migrated from the frontend to the backend soon. Try to put the core functionality into functions that don't rely on React features like hooks.

[prayagd]

@ebma should we estimate this?

[ebma]

Yes let's do that 👍

[prayagd]

Hey team! Please add your planning poker estimate with Zenhub @ebma @gianfra-t @Sharqiewicz