Skip to content

Conversation

acatangiu
Copy link
Contributor

@acatangiu acatangiu commented Oct 5, 2025

Context

Asset Hub currently supports registering following types of assets:

  1. Local Assets (also called trust-based assets), with u32 asset ID, asset creatable by Signed accounts and managed by PalletInstance(50).
  2. Foreign Assets, Location as asset ID, creatable only by external locations over XCM.

For "foreign assets", the current code assumes and enforces that the asset is teleportable with its original location/creator.

Some ecosystem parachains would want to register foreign assets on Asset Hub, but not also have them teleportable, not have Asset Hub act as a reserve for the asset. Multiple reserve locations adds reserve management overhead for teams, and some don't want to do it.

E.g. for HOLLAR to be registered to Asset Hub, Asset Hub would have to allow reserve-based foreign assets.

Solution

This PR adds a new pallet-assets-reserves that can be used to configure the trusted reserves (as seen by the local chain) on a per-asset basis.

It also adds runtime machinery to use the assets reserves information when reasoning about XCM teleports and XCM reserve-based transfers.

For each asset, the base chain described in its asset id location is considered a default reserve chain without it having to be explicitly configured.
Any other chain that should be assumed as a trusted reserve needs to be marked as such in pallet-assets-reserves by the asset's Owner or Admin.
When the local chain is also marked as a reserve (Here is added to the list of reserves) for a particular asset, then that asset can be teleported between the local chain and any other reserve location.

By default, on asset creation, no explicit reserve chain is configured, this results in foreign assets to be reserve-based assets by default and not teleportable. To make them teleportable with their origin chain, Here needs to be added as a reserve (local chain to also be a reserve).

AH considerations

Since there are already a number of Foreign Assets already registered, and have been teleportable since registration, this PR also adds a migration that adds Here as a reserve for existing foreign assets, so as not to change any existing behaviors.

Newly registered foreign assets will not be teleportable by default - which is the desired result of this PR.
They can be configured to be teleportable by the asset's Owner or Admin, post-creation.

@acatangiu acatangiu force-pushed the assets-reserves branch 2 times, most recently from 33da191 to 224f485 Compare October 6, 2025 12:01
@acatangiu acatangiu added T6-XCM This PR/Issue is related to XCM. T14-system_parachains This PR/Issue is related to system parachains. labels Oct 6, 2025
@acatangiu acatangiu requested a review from a team October 6, 2025 12:27
@acatangiu acatangiu force-pushed the assets-reserves branch 2 times, most recently from da1450b to 772734b Compare October 6, 2025 12:41
_Context_

Asset Hub currently supports registering following types of assets:
1. Local Assets (also called trust-based assets), with `u32` asset ID,
asset creatable by Signed accounts and managed by `PalletInstance(50)`.
2. Foreign Assets, `Location` as asset ID, creatable only by external
locations over XCM.

For "foreign assets", the current code assumes and enforces that the
asset is teleportable with its original location/creator.

Some ecosystem parachains would want to register foreign assets on Asset Hub,
but not also have them teleportable, not have Asset Hub act as a reserve for
the asset. Multiple reserve locations adds reserve management overhead for
teams, and some don't want to do it.

E.g. for HOLLAR to be registered to Asset Hub, Hydration wants Asset Hub to
allow reserve-based foreign assets.

_Solution_

This PR adds a new `pallet-assets-reserves` that can be used to configure
the trusted reserves (as seen by the local chain) on a per-asset basis.

It also adds runtime machinery to use the assets reserves information when
reasoning about XCM teleports and XCM reserve-based transfers.

For each asset, the base chain described in its asset id location is
considered a default reserve chain without it having to be explicitly
configured.
Any other chain that should be assumed as a trusted reserve needs to be
marked as such in `pallet-assets-reserves` by the asset's Owner or Admin.
When the local chain is also marked as a reserve (`Here` is added to the
list of reserves) for a particular asset, then that asset can be teleported
between the local chain and any other reserve location.

By default, on asset creation, no explicit reserve chain is configured,
this results in foreign assets to be reserve-based assets by default and
not teleportable. To make them teleportable with their origin chain,
`Here` needs to be added as a reserve (local chain to also be a reserve).

_AH considerations_

Since there are already a number of Foreign Assets already registered,
and have been teleportable since registration, this PR also adds a
migration that adds `Here` as a reserve for existing foreign assets,
so as not to change any existing behaviors.

Newly registered foreign assets will not be teleportable by default,
which is the desired result of this PR.
They can be configured to be teleportable by the asset's Owner or Admin,
post-creation.

Signed-off-by: Adrian Catangiu <[email protected]>
@acatangiu
Copy link
Contributor Author

Alternative to #9948

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

T6-XCM This PR/Issue is related to XCM. T14-system_parachains This PR/Issue is related to system parachains.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant