Pure Proxies
Pure proxies are very different from other proxy types. So far, the proxies we have described are existing accounts assigned as proxies by a primary account. These proxies act on behalf of the primary account, reducing the exposure of the primary account's private key. Remember, the more often we use an account's private key to sign transactions, the more we expose that key to the internet, increasing the visibility of that account. The purpose of a proxy is thus to draw the attention of potential attackers away from the primary account, as proxies' private keys will be used most of the time to perform actions on behalf of the primary account.
Pure proxies are new accounts that are created (not assigned) by a primary account. That primary account then acts as any proxy on behalf of the pure proxy. Pure proxies are keyless non-deterministic accounts as they do not have a private key (keyless), but they have a randomly generated address (non-deterministic). Also, nobody owns a pure proxy, as nobody has a private key to control them.
Why Pure Proxy?¶
In the Polkadot ecosystem, pure proxies are helpful in efficiently managing multi-signature accounts. Multi-signature accounts are deterministic, which means that once a multisig is created, the signatories cannot be changed. If one of the signatories wants to leave the multisig, a new multisig must be created. Pure proxies allow keeping the same multisig address when the multisig configuration changes (signatories and threshold). See more examples about using pure proxies with multisigs here.
Use of Pure Proxy¶
Use dApps that deal with pure proxies for you
Because dealing with pure proxies is complicated, using multisig applications that deal with the complexity for you is recommended.
The use of the pure proxy is strictly bound to the relationship between the pure proxy and the any proxy. Note that the any proxy does not necessarily be the one who created the pure proxy in the first place. Hence, pure proxies are not really owned by somebody but can be controlled.
Once that relationship between the pure proxy and its any proxy is broken, the pure proxy will be inaccessible.
Pure proxies are non-deterministic accounts, meaning that if we lose one pure proxy, the next one we create from the same primary account will have a different address.
Pure proxies cannot sign anything because they do not have private keys. However, although they do
not have private keys and cannot sign any transaction directly, they can act as proxies (or better,
proxy channels) within proxy calls via proxy.proxy extrinsic. For example, having pure
proxies within a multisig is possible. Using proxy calls, it is possible to use the any proxy to call the
pure proxy, which in turn will do a multisig call.
History of Pure Proxies¶
In the past, pure proxies were called anonymous proxies. However, pure proxies are not anonymous because they have an address spawned by a primary account acting as any proxy. Even if any proxy changes, it is still possible to find who generated the anonymous proxy by going backward using a block explorer. There was thus the need to change the name of anonymous proxy. People suggested keyless accounts since they do not have a private key and are proxied accounts. However, multisig accounts are also keyless (but deterministic). Moreover, even if anonymous proxies are proxied accounts, they can still act as proxies and control other accounts via proxy calls (see multisig example below). Thus, the name that has been chosen is pure proxy. If you want to know more about the reasoning behind the renaming of pure proxies, see the discussion in this PR or the discussion on Polkadot forum.
Remote Proxies¶
Remote proxies enable the utilization of pure proxy accounts, initially established on a designated parent chain (i.e., the Polkadot relay chain), for actions on a separate target chain (i.e., Polkadot Asset Hub). This is achieved by providing a cryptographic proof, specifically a storage proof anchored to the parent chain's storage root. This proof verifies that the specified pure proxy account indeed exists and is valid on the parent chain at a particular point in time.
An example would be a multi-signature account, where a pure proxy is created on the Polkadot Relay Chain. To cosign a transaction on Polkadot Asset Hub, this keyless pure proxy cannot directly interact. The remote proxy mechanism bridges this gap. Leveraging the remote proxy pallet on Asset Hub, a transaction can be constructed that includes a storage proof demonstrating the pure proxy's existence on the relay chain. Upon successful verification of this proof, the Asset Hub chain allows actions to be executed as if they originated from the pure proxy on the Relay Chain.
Once a successful remote proxy call is executed, a ProxyExecuted event should be visible.
Here is an example usage of a remote proxy call: If you have a pure proxy setup on Kusama Relay Chain, you can use this tool to construct a transaction that transfers all funds from the pure proxy account address to its controlling account address on Kusama Asset Hub, even though no proxy setup is present on Kusama Asset Hub. The underlying code is available on GitHub, and is based on this blog post. For more context on how remote proxies work and why they're helpful, check out this blog post.
Polkadot-JS Guides
If you are an advanced user, see the Polkadot-JS guides about pure proxy accounts.