You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Nov 15, 2023. It is now read-only.
Provide instructions allowing remote chains to lock/unlock local assets. This allows for the possibility of separation of system-parachains such as conviction-voting and staking from token-hosting parachains (e.g. Statemint).
The basic idea is that VotingChain (i.e. the system-parachain hosting conviction-voting) would have a remote-locks pallet. This allows locks of funds sitting on Statemint which are initiated by VotingChain to be tracked and queried synchronously. An API will be built into Conviction Voting pallet allowing for alternative means of the querying and locking of funds, allowing for funds held and locked remotely to be known and utilised.
Basic API. This works by the user issuing a lock_asset(user, dots, VotingChain) on Statemint, which then locks dots such that they're only unlockable by VotingChain. Statemint automatically sends a NoteAssetLocked(dots, user) to VotingChain, which checks that Statemint is a teleport target (it is) and registers the lock in a map in PalletXcm. The user then casts their vote on VotingChain, which is configured to check the remote locks in PalletXcm and in doing so determines that the appropriate funds were locked and the votes should be put in place. It registers with the PalletXcm the amount of the lock which is now in use so that the user cannot request that PalletXcm unlock more funds than it should.
At some point later, the user may have the Conviction-Voting pallet unlock the funds which were needed for voting according to its own logic. Instead of unlocking the balance directly, it registers with PalletXcm that (a portion of) the remote locked funds are no longer needed. This allows the user to execute a second dispatchable in PalletXcm unlock_asset with the newly unused locked funds to have VotingChain send UnlockAsset back to Statemint which unlocks the DOT.
New dispatchable in PalletXcm lock_asset(origin, asset: MultiAsset, unlocker: MultiLocation): Locks asset owned by origin with ID (b"xcm_lock", unlocker).encode(). Sends a NoteAssetLocked message to unlocker with asset and origin (converted to a MultiLocation). NOTE: This is a bit "dangerous" since of unlocker is not a chain which recognises the NodeAssetLocked message and allows for the sending of an UnlockAsset, then the assets may not be unlockable without governance intervention.
New dispatchable in PalletXcm unlock_asset(origin, asset: MultiAsset, locker: MultiLocation): Sends an UnlockAsset instruction to locker for asset IFF there is a registered remote lock for asset and it is currently unused.
NoteAssetLocked(asset, owner): Notes that owner locked asset guaranteeing that it will be held under custody at least until a corresponding call from UnlockAsset is received.
UnlockAsset(asset, owner): Unlocks asset owned by owner with ID (b"xcm_lock", origin).encode().
The text was updated successfully, but these errors were encountered:
Provide instructions allowing remote chains to lock/unlock local assets. This allows for the possibility of separation of system-parachains such as conviction-voting and staking from token-hosting parachains (e.g. Statemint).
The basic idea is that VotingChain (i.e. the system-parachain hosting conviction-voting) would have a remote-locks pallet. This allows locks of funds sitting on
Statemint
which are initiated by VotingChain to be tracked and queried synchronously. An API will be built into Conviction Voting pallet allowing for alternative means of the querying and locking of funds, allowing for funds held and locked remotely to be known and utilised.Basic API. This works by the user issuing a
lock_asset(user, dots, VotingChain)
on Statemint, which then locksdots
such that they're only unlockable by VotingChain. Statemint automatically sends aNoteAssetLocked(dots, user)
to VotingChain, which checks that Statemint is a teleport target (it is) and registers the lock in a map inPalletXcm
. The user then casts their vote on VotingChain, which is configured to check the remote locks inPalletXcm
and in doing so determines that the appropriate funds were locked and the votes should be put in place. It registers with the PalletXcm the amount of the lock which is now in use so that the user cannot request that PalletXcm unlock more funds than it should.At some point later, the user may have the Conviction-Voting pallet unlock the funds which were needed for voting according to its own logic. Instead of unlocking the balance directly, it registers with PalletXcm that (a portion of) the remote locked funds are no longer needed. This allows the user to execute a second dispatchable in PalletXcm
unlock_asset
with the newly unused locked funds to have VotingChain sendUnlockAsset
back to Statemint which unlocks the DOT.lock_asset(origin, asset: MultiAsset, unlocker: MultiLocation)
: Locksasset
owned byorigin
with ID(b"xcm_lock", unlocker).encode()
. Sends aNoteAssetLocked
message tounlocker
withasset
andorigin
(converted to aMultiLocation
). NOTE: This is a bit "dangerous" since ofunlocker
is not a chain which recognises theNodeAssetLocked
message and allows for the sending of anUnlockAsset
, then the assets may not be unlockable without governance intervention.unlock_asset(origin, asset: MultiAsset, locker: MultiLocation)
: Sends anUnlockAsset
instruction tolocker
for asset IFF there is a registered remote lock forasset
and it is currently unused.NoteAssetLocked(asset, owner)
: Notes thatowner
lockedasset
guaranteeing that it will be held under custody at least until a corresponding call fromUnlockAsset
is received.UnlockAsset(asset, owner)
: Unlocksasset
owned byowner
with ID(b"xcm_lock", origin).encode()
.The text was updated successfully, but these errors were encountered: