I hope this is the right place for technical questions.
We’d like to remove root priveledges from the BEEFY asset on AssetHub (id:420), so no more assets can be minted nor other priviledged extrinsics be called.
It seems like the steps to make this possible are:
create a proxy account by calling the proxy.create_pure extrinsic with these params: Any, 0, 0
transfer ownership of the token to that proxy account by calling assets.transferOwnership with these params: 420,
kill the proxy account by calling proxy.kill_pure with these params: , 0, Any, ,
Now, obviously I don’t want to make any mistake here, so this is why I’d like to hear whether these steps are correct. Also, I’m not sure how to figure out the <extrinsicIndexAtStep1> value.
Unfortunately I didn’t find any info on the wiki or forum where this is explained.
PS - Any helpful contributors to this discussion will be rewarded with a smoll $BEEFY allocation
Create a pure proxy with proxy.create_pure(Any, 0, 0). When this is finalized, take note of the block number and extrinsic index at which your pure proxy is created because you will need it later to kill it.
You will need to call first assets.set_team(420, pure_proxy, pure_proxy, pure_proxy) to transfer the admin, minting and freezing privileges to the pure proxy.
Then call assets.transfer_ownership(420, pure_proxy) to transfer ownership to the pure proxy.
Triple check that the pure proxy is not holding any asset 420, unless you intend for these funds to be locked forever.
You will need to call proxy.proxy(pure_proxy, proxy.kill_pure(spawner, Any, 0, block, extInd)) with the account that spawned and controls the pure proxy. Here the block and extInd are the block number and extrinsic index of the create_pure call that you made earlier. An example on Polkadot Asset Hub: Subscan | Aggregate Substrate ecological network high-precision Web3 explorer
Better to test the steps on a testnet like Rococo or Westend first before attempting on Polkadot
Good luck!
P.S. We are working on a UI for asset management in Asset Hub that will include the ownership revoke functionality. The beta version should be out in a week or two.
For owner revocation, we’ve been wondering if it would be easier to just transfer privileges to a keyless account that no-one controls? The derivation of the address will be the same as how treasury and sovereign account address are derived.
The advantages will be that there’s no need to set up and kill pure proxies for asset owners. And if the address is well-known, it will be much easier for UIs to detect if ownership has been revoked for an asset. With the pure proxy approach, UIs will have to set up an indexer to check for create and kill pure extrinsics because this data cannot be retrieved onchain.
Curious to know what others think about this approach.
Yea, calling revoke_all_privilege would be much easier and straight-forward to verify indeed.
@sodazone thanks for the detailed instructions, looks like I was missing the set_team extrinsic in my OP. Regarding to the keyless accounts, according to the wiki, proxy accounts are keyless accounts as well:
In Polkadot there are some exceptions of accounts that do not have known private keys (i.e. keyless accounts). Such accounts are multi-signature accounts, pure proxies, and system accounts
Did you mean to say system accounts instead? Multi-sig doesn’t really make sense in this context I guess…
In any case, if you were referring to a future implementation to help fixing this, I think the revoke_all_privilege extrinsic from the PR joe mentioned is the cleanest way forward.
I think what @sodazone said makes sense. Although technically one could say that every account is a “system account” (even those with keys), these “keyless accounts” can be in two categories:
User accounts, e.g. multi-sig, pure proxy. These accounts are keyless but are controlled by other accounts with keys.
System accounts, e.g. Treasury, Collator pot. These accounts are keyless but managed by on-chain logic.
Regarding using a keyless account for revocation.
As Joe says it relies on social consensus about the string and hash used to generate the address, e.g. “dest/unreachable”. Anyone can get the same hash using the same string so it’s easy to validate. The big drawback is the consensus on the string value; pure proxies signal the revocation without a well-known string, but are hard to track.
Undoubtedly, it is better to have revocations, burns, etc. built-in with proper logic instead of using an address hack or pure proxies.
The pure proxy approach could still make sense, assuming the lack of built-in logic for the use case, to “time-lock” tokens. The mechanisms would be to transfer the tokens to the proxy, schedule a transfer to recover the tokens in the future and then killing the proxy (theoretically, but not tested, will it actually work? )
We were imagining using this case for time-locking LP tokens as an anti-rug mechanism, what do you think @BEEFY?
PS: the beta app will public, we will post the URL in the forum.
Woww having them time-locked would be amazing indeed! If we could have a staking mechanism that way, even if it’s a lazy one, it would be great.
So you time-lock the tokens (instead of staking) for a specific amount of time (e.g. 1 week) and get a return (e.g. 1%), once the time-lock expires. To make the payout of the return (1%) trustless we’d need some kind of programmable logic (smart contract) which is not straight forward on Polkadot. The only solution that came to our minds would be to deploy a smart contract (EVM/Ink!) on Moonbeam or Astar that encapsulates that logic, but we if there would be a way to execute some code like that on one of the system chains it would be even better. Hopefully we don’t have to wait for JAM to see something like that become reality.
PS: the beta app will public, we will post the URL in the forum.
Looking forward! Is the code open source yet or are you working on it in a more confidential setting atm?
Turns out that Asset Hubs do not have the scheduler pallet, and relay/other system chains only allow privileged origins to make scheduled calls
Anyway, for the case that you want to achieve, smart contracts will be more trustless and secure for the end users. The scheduler+proxy time-lock we described is executed offchain and users need to trust that the asset issuer is making the right call, and not reversing it before killing the proxy. You’ll also have more flexibility in designing your incentive mechanisms with a contract, although with the downside of more cross-chain overhead.
We plan to open source it as soon as we have a stable release!
We implemented the revoke privileges with the pure proxy approach for now. When revoke_all_privilege call is released, we will update the UI to use the native approach.
)
