paritytech / asset-transfer-api Goto Github PK

The transfer of native assets to its origin chain involve using a teleportAssets or limited call. There needs to be some sort of logic where we can check if the passed in asset is a Native asset. Ex: GML not 18

This can involve some sort of registry, and lookup using the assets pallet.

For now this support should only be for system parachain directions.

This is important for when we are declaring how we should search through the registry.

Since the layout of the registry works like:

const registry = {
    polkadot: { ... },
    kusama: { ... },
    westend: { ... },
}

We want to ensure we connect to the correct chain. One solution would be to make a map of each key. So for example:

polkadot = [
    'acala',
    'moonbeam',
    ...
]

And check the specName we have locally against the registry. If it does not exist then we need to throw an error.

Currently createTransferTransaction 3 different values in 2 formats depending on the format option. The options are call, payload, and submittable. Either a hex will be returned or a polkadot-js Submittable type.

This has been on my mind since designing and implementing the API, but to make errors clearing and following a more rust like syntax return a Result, that either has the return value or an error attached. Along with that should we change that return value to be a object with the following metadata attached:

If the Result is ok, it would need to be unwrapped using unwrap.

{
    xcmVersion: string,
    direction: This will be the xcmDirection or local for a local transaction.
    result: (This will be the call payload or submittable)
}

If the Result is an err, it would have the following structure:
{
type: The type of error this is
msg: The error message.
}

Open to adding more information as well.

@IkerAlus Curious on your thoughts.

This should take in a SubmittableExtrinsic and return either payload | call | polkadot- js

When creating assets in createXcmTypes, will the amounts param always be length of 1? If so we dont need to loop through and we can grab the initial value.

Currently typedoc just creates the markdowns, but we should generate an html index file with the given markdowns for a good single page UI docs. Hosted on github pages.

If you are given assets such as ['1', '2', '3', 'TST', 'GLMR'] this would be the correct format.

If you are given assets such as ['1', '2', '3', 'TST', 'hello'] this would be incorrect.

If the value is a token we want to check that against the registry. We can use findRelayChain function to help establish which relay chain is on our network and then we can check all the tokens under that object.

You may need to also pass in the specName and registry to checkXcmTxInputs

We should remove any support for V0 and replace it with V2. This also means when we start adding V3 it should replace V1 and that should be removed for the long term and or be deprecated.

Ex: Between a AccountId32 and AccountId20

This has to do with ethereum addresses, and should be taken into account when constructing the xcm message. createXcmTypes is where we pass in the accountId, and we should have some process in place to ensure its the correct type.

Should users be able to decode the xcm message transfer that they construct?

Currently the unreliable Id's that i inputted are from a local testing standpoint and were manually added to those arrays, but it would be a great improvement to remove those values and have a timer on each api connection and when the timer is surpassed to skip adding that chains tokens to the registry.

Build a multilocation factory that focuses on:

p to p
r to p
p to r

Lets remove the I in front of any interface type and just have the names be there normal names.

For XCM's of system parachain origin we should check that string number asset id inputs are valid and exist

Ensure published package has d.ts files.

Given the following beneficiary construction, should the network field be added the the AccountId field.

https://github.com/paritytech/asset-transfer-api/blob/main/src/createXcmTypes/SystemToPara.ts#L50

For example: https://github.com/paritytech/polkadot/blob/0960b145eeff82cc46d21f4626e14ef39a53cfde/xcm/src/v3/multiasset.rs#L516

The following indicates we must have properly ordered assets.

TypeStrong/typedoc#1485 (comment)

Good reference above^

Right now main is broken because I switched over addresses to be only SS58 and have rejected hexes, but that breaks the api. Polkadot-js only accepts a hex value for constructing xcm messages.

Since not all parachains are created equal we need to ensure we can find the correct call in the pallet.

This is not an immediate need, but should be taken into account when we implement ParaTo* cases

This should include SystemToPara and RelayToPara