centrifuge / apps

Monorepo for Centrifuge frontends, including Centrifuge App, onboarding api, and Fabric design system.
GNU Lesser General Public License v3.0
27 stars 16 forks source link

Crosschain borrow automation #1992

Closed annamehr closed 1 month ago

annamehr commented 7 months ago

Protocol specs UI specs

Background

Given the merge of remote account derivation via xcm users/pallets/on-chain accounts/etc. are now able to have safe remote accounts on all system parachains. This enables us to make interaction with these chains safer and easer for users

The overall goal is that issuers can on-ramp and off-ramp USDC from Polkadot AssetHub without directly interacting with AssetHub. All interactions MUST be triggered through XCMs send from Centrifuge.

The usual on-ramp flow includes three steps:

The last step will not be triggered on AssetHub but on Centrifuge. We can abstract away all complexity for the end-user, making it much safer than using polkadot.js.

The usual off-ramp flow includes x steps:

:::info :bulb: We can XCM-Transfer directly into the off-ramp account on AssetHub as Circle is rejecting those transfers, leading to a loss of funds. :::

Requirements

Foreseable Obstacles

:::danger :warning: Testing is only possible via Fudge, Altair and on Centrifuge. Dev and Demo do not work well here. :::

:computer: Technical Spec

Option A - Preferred

Adapting the existing runtime configuration to allow a batch(xtokens::transfer(..), pallet_xcm::send(..)). Where the first generates an XCM that transfers the funds to the remote controlled account, and the second creates the actual transaction to send tokens.

:::info :bulb: Generating the derived account on other chains is trivial by using our AccountConversionApi.conversionOf runtime api with the multilocation that the receiving chain will see. :::

Adapt Runtime Configuration

Option B

Creating correct XCM messages is hard - the orml-xtokens provides a good insight into how tedious it is to transfer assets with XCM. Unfortunately, most of the pallets method are private and not well suitable for composition.

:::success :notebook: Proposal for...

:::

pallet-restricted-xtokens Extension

Types
RemoteTransact

A type that allows to easily create the right Instruction.

pub struct RemoteTransact<T: Config> {
    call: BoundedVec<u8, T::MaxTransact>,
    require_weight_at_most: Weight,
}

impl<T: Config> Into<Instruction<()>> for RemoteTransact<T> {
    fn into(self) -> Instruction<()> {
        Instruction::Transact {
            origin_kind: OriginKind::SovereignAccount,
            require_weight_at_most: self.require_weight_at_most,
            call: From::<Vec<u8>>::from(self.call.into()),
        }
    }
}
Calls

The idea is to extend our pallet-restricted-xtokens with three additional calls:


fn remote_transact

:::info :bulb: An extrinsics allows to create an XCM that is send to another chain and executes a transaction on behalf of the sender on Centrifuge via its remote account. :::


:link: Links

mustermeiszer commented 1 month ago

Closing as we will have a new onramping flow that will be easier in handling that as we can use a simple transfer