pub trait TransactAsset {
// Provided methods
fn can_check_in(
_origin: &Location,
_what: &Asset,
_context: &XcmContext
) -> Result<(), Error> { ... }
fn check_in(_origin: &Location, _what: &Asset, _context: &XcmContext) { ... }
fn can_check_out(
_dest: &Location,
_what: &Asset,
_context: &XcmContext
) -> Result<(), Error> { ... }
fn check_out(_dest: &Location, _what: &Asset, _context: &XcmContext) { ... }
fn deposit_asset(
_what: &Asset,
_who: &Location,
_context: Option<&XcmContext>
) -> Result<(), Error> { ... }
fn withdraw_asset(
_what: &Asset,
_who: &Location,
_maybe_context: Option<&XcmContext>
) -> Result<AssetsInHolding, Error> { ... }
fn internal_transfer_asset(
_asset: &Asset,
_from: &Location,
_to: &Location,
_context: &XcmContext
) -> Result<AssetsInHolding, Error> { ... }
fn transfer_asset(
asset: &Asset,
from: &Location,
to: &Location,
context: &XcmContext
) -> Result<AssetsInHolding, Error> { ... }
}Expand description
Facility for asset transacting.
This should work with as many asset/location combinations as possible. Locations to support may
include non-account locations such as a [Junction::Parachain]. Different
chains may handle them in different ways.
Can be amalgamated as a tuple of items that implement this trait. In such executions, if any of
the transactors returns Ok(()), then it will short circuit. Else, execution is passed to the
next transactor.
Provided Methods§
fn can_check_in(
_origin: &Location,
_what: &Asset,
_context: &XcmContext
) -> Result<(), Error>
fn can_check_in( _origin: &Location, _what: &Asset, _context: &XcmContext ) -> Result<(), Error>
Ensure that check_in will do as expected.
When composed as a tuple, all type-items are called and at least one must result in Ok.
fn check_in(_origin: &Location, _what: &Asset, _context: &XcmContext)
fn check_in(_origin: &Location, _what: &Asset, _context: &XcmContext)
An asset has been teleported in from the given origin. This should do whatever housekeeping is needed.
NOTE: This will make only a best-effort at bookkeeping. The caller should ensure that
can_check_in has returned with Ok in order to guarantee that this operation proceeds
properly.
Implementation note: In general this will do one of two things: On chains where the asset is native, it will reduce the assets from a special “teleported” account so that a) total-issuance is preserved; and b) to ensure that no more assets can be teleported in than were teleported out overall (this should not be needed if the teleporting chains are to be trusted, but better to be safe than sorry). On chains where the asset is not native then it will generally just be a no-op.
When composed as a tuple, all type-items are called. It is up to the implementer that there
exists no value for _what which can cause side-effects for more than one of the
type-items.
fn can_check_out(
_dest: &Location,
_what: &Asset,
_context: &XcmContext
) -> Result<(), Error>
fn can_check_out( _dest: &Location, _what: &Asset, _context: &XcmContext ) -> Result<(), Error>
Ensure that check_out will do as expected.
When composed as a tuple, all type-items are called and at least one must result in Ok.
fn check_out(_dest: &Location, _what: &Asset, _context: &XcmContext)
fn check_out(_dest: &Location, _what: &Asset, _context: &XcmContext)
An asset has been teleported out to the given destination. This should do whatever housekeeping is needed.
Implementation note: In general this will do one of two things: On chains where the asset is native, it will increase the assets in a special “teleported” account so that a) total-issuance is preserved; and b) to ensure that no more assets can be teleported in than were teleported out overall (this should not be needed if the teleporting chains are to be trusted, but better to be safe than sorry). On chains where the asset is not native then it will generally just be a no-op.
When composed as a tuple, all type-items are called. It is up to the implementer that there
exists no value for _what which can cause side-effects for more than one of the
type-items.
fn deposit_asset(
_what: &Asset,
_who: &Location,
_context: Option<&XcmContext>
) -> Result<(), Error>
fn deposit_asset( _what: &Asset, _who: &Location, _context: Option<&XcmContext> ) -> Result<(), Error>
Deposit the what asset into the account of who.
Implementations should return XcmError::FailedToTransactAsset if deposit failed.
fn withdraw_asset(
_what: &Asset,
_who: &Location,
_maybe_context: Option<&XcmContext>
) -> Result<AssetsInHolding, Error>
fn withdraw_asset( _what: &Asset, _who: &Location, _maybe_context: Option<&XcmContext> ) -> Result<AssetsInHolding, Error>
Withdraw the given asset from the consensus system. Return the actual asset(s) withdrawn,
which should always be equal to _what.
The XCM _maybe_context parameter may be None when the caller of withdraw_asset is
outside of the context of a currently-executing XCM. An example will be the charge_fees
method in the XCM executor.
Implementations should return XcmError::FailedToTransactAsset if withdraw failed.
fn internal_transfer_asset(
_asset: &Asset,
_from: &Location,
_to: &Location,
_context: &XcmContext
) -> Result<AssetsInHolding, Error>
fn internal_transfer_asset( _asset: &Asset, _from: &Location, _to: &Location, _context: &XcmContext ) -> Result<AssetsInHolding, Error>
Move an asset from one location in to another location.
Returns XcmError::FailedToTransactAsset if transfer failed.
§Notes
This function is meant to only be implemented by the type implementing TransactAsset, and
not be called directly. Most common API usages will instead call transfer_asset, which in
turn has a default implementation that calls internal_transfer_asset. As such, please
do not call this method directly unless you know what you’re doing.
fn transfer_asset(
asset: &Asset,
from: &Location,
to: &Location,
context: &XcmContext
) -> Result<AssetsInHolding, Error>
fn transfer_asset( asset: &Asset, from: &Location, to: &Location, context: &XcmContext ) -> Result<AssetsInHolding, Error>
Move an asset from one location in to another location.
Attempts to use internal_transfer_asset and if not available then falls back to using a
two-part withdraw/deposit.
Object Safety§
This trait is not object safe.