No `UnlockAsset` instruction found for remote locking and locking overlap examples

[Chralt98]

Hey valuable XCM community,

I am currently checking the XCM remote lock examples. In there you can see the following comments:

https://github.com/paritytech/xcm-docs/blob/0e4a5fb58b9421288f4fc5e6def9c5d8b6b3f065/examples/src/10_locks/mod.rs#L11

https://github.com/paritytech/xcm-docs/blob/0e4a5fb58b9421288f4fc5e6def9c5d8b6b3f065/examples/src/10_locks/mod.rs#L79

But the UnlockAsset xcm instruction from Parachain B for the remote_locking_on_relay example was never sent:

https://github.com/paritytech/xcm-docs/blob/0e4a5fb58b9421288f4fc5e6def9c5d8b6b3f065/examples/src/10_locks/mod.rs#L47-L66

And the UnlockAsset xcm instruction from Parachain B for the locking_overlap example was never sent:

https://github.com/paritytech/xcm-docs/blob/0e4a5fb58b9421288f4fc5e6def9c5d8b6b3f065/examples/src/10_locks/mod.rs#L134-L158

So my question is: How can the relay chain locks be modified, if the unlocker chain didn't send a UnlockAsset instruction to the relay chain?

[franciscoaguirre]

Hello! Thanks for your question.

In both examples, the instruction that modifies the locks in the relay chain is RequestUnlock, this instruction is sent to the unlocker, so in the examples Parachain B or C, and it's the unlocker that sends an UnlockAsset to the relay in response to this message.

Also, reminder that substrate.stackexchange.com exists and is a good place to get your questions answered

[Chralt98]

Thanks for your quick response @franciscoaguirre !

However, I would expect that the unlocker (in this particular case it's ParaB) actually sends an UnlockAsset instruction to the relaychain, but I can't find it in the test case.

So you are basically saying that after the xcm message RequestUnlock is sent, the Unlocker Parachain receives this message and internally responses to the relaychain with UnlockAsset, which instruction we can't visually see in the test-case?

If the above is true, then the unlocker Parachain has no control over whether the funds should stay locked on the lock Parachain? I imagined the feature of remote locks to be that a the unlocker chain has full control of how long the funds of the locker chain are going to be locked.

Did I misunderstand your response?

PS: Thanks for referring me to the stackexchange portal. Since I started the discussion here already, I am reluctant to move it to the stackexchange right now. But for future questions I will use the stackexchange platform.

[franciscoaguirre]

So you are basically saying that after the xcm message RequestUnlock is sent, the Unlocker Parachain receives this message and internally responses to the relaychain with UnlockAsset, which instruction we can't visually see in the test-case?

Correct

If the above is true, then the unlocker Parachain has no control over whether the funds should stay locked on the lock Parachain? I imagined the feature of remote locks to be that a the unlocker chain has full control of how long the funds of the locker chain are going to be locked.

The unlocker is the only one that can send the UnlockAsset instruction. This works as a sort of delegation, they can control whether they unlock the assets or not. But we give the owner the final say by letting them request an unlock anytime they like.

This is not to say you can't create a system that makes sure the owner can only unlock the assets if a particular condition is met, which is verified by the unlocker. You'd just need to interpret the instruction differently. If this functionality is relevant an RFC could be opened for integrating it in the language spec.

PS: Thanks for referring me to the stackexchange portal. Since I started the discussion here already, I am reluctant to move it to the stackexchange right now. But for future questions I will use the stackexchange platform.

Sounds good 👍

[Chralt98]

Interesting. But for what exact purpose is this feature required then (as implemented)? Yeah, I will do a RFC, if I prioritise the time for it.

Yeah, exactly as you said: I just imagined an unlocker parachain that has the power to keep funds on other chains locked, until a certain condition is met to get it unlocked. Think about an unlocker parachain that allows Polkadot holders to lock their staked DOTs on behalf of the unlocker parachain to be able to vote on the unlocker parachain. If the vote period on the unlocker parachain is over, the parachain allows to let the Polkadot holders unlocking their funds again.

This is currently not possible with the staked funds on Polkadot, but only with an XCM transfer from the relaychain to the parachain and then lock the funds on the parachain internally (orml_tokens lock) and only allow to XCM transfer funds back if a certain condition is met (in my case if the voting period on the parachain is over).

[Chralt98]

Can a user call LockAsset { asset: (Here, full_balance).into(), unlocker: (Parachain(2)).into() }, on funds, which are in the staking system?

PS: I already did a stackexchange question a long time ago about this here.

[Chralt98]

I think the answer is yes, because LockAsset uses the balance locks, which overlap with staking funds :-)

[Chralt98]

I think my feature is not wanted, because another parachain (A) could then completely lock funds on another chain (B) forever, I guess. However the governance of the chain B should be able to unlock the funds of accounts, but not the locker account itself. Mhh, I am rethinking this feature.. Maybe chain A could specify in a XCM how long the chain B has to lock the funds and after that Alice can unlock. And chain B can set the maximum lock period for their chain, which can't be exceeded by the chain A XCM instructions.