Ecosystem Proxy

Currently, nearly every (or almost every :P) chain in the Polkadot ecosystem has pallet-proxy deployed. When users wish to utilize a proxy on one of these chains, they must manually register the proxy, which can be tedious. This process could be simplified through a UI/DApp. However, complications arise when a user attempts to replicate a pure proxy on a different chain, as the generation of a pure proxy involves data such as the current block number and extrinsic index. These values are not directly controllable by the user, making it impractical to replicate the proxy on another chain.
Some users have already trapped their funds by requesting payouts on AssetHub to a proxy account that only exists on the relay chain. These issues could only be solved by manually replicating the pure proxy on AssetHub with a root referendum.

Issue warnings in the UI

An immediate solution would be for UIs to issue warnings when a user attempts to send funds to a pure proxy on a remote chain. This way it would be prevented that funds get trapped in the first place. Although this is not the ideal solution, it could be implemented quickly.

Pure Proxy replication

There exists RFC#111 that proposes a solution to fix the issue. The core idea is to replicate proxy accounts across chains. The replication would be done using a XCM message from chain A to chain B. In this process chain B would need to trust chain A that the data is correct. This solution requires that the proxies are replicated in the entire ecosystem. Personally, I am not in favor of replicating data on every chain and having "random" chains trust each other. A better solution might be for everyone in the ecosystem to create their proxies on the People chain. From there the other chains could use a proof to verify the existence of a proxy. This way the data doesn't need to be replicated and the chains would only need to trust People chain.

Proxies on the People chain

The People chain already serves as a repository for people-related information. It would be logical for the People chain to act as the central proxy registry within the ecosystem. This doesn't mean that pallet-proxy should be removed from all other chains or that proxies are only registered on the People chain. One downside of maintaining proxies on the People chain is that each proxy call requires a proof from the People chain. The size of the proof depends on the number of registered proxy accounts. However, this could be optimized in the future by altering the state layout to reduce proof size. A mixed mode could also be considered, where it is incentivized to keep proxy accounts on the People chain, but if a proxy account is frequently required, it could be replicated to the target chain via RFC#111.

Proof of proxy

The "proof of proxy" is a state proof from the People chain. It would consist of the pallet_proxy::Proxies entry for the proxy account. This entry is enough to proof that the calling account has proxy rights for the proxy account. On the chain where the remote proxy call should be executed, the proof will need to be verified. In Polkadot each parachain gets a state proof from the relay chain, this contains for example the XCM messages and other important information. The state proof could be extended to include the header of the People chain. The header contains the storage root and this can be used to verify the "proof of proxy". As the relay chain is trusted, fetching the headers from the relay chain inherits the same trust and no other verification of these headers is required. Each parachain that would want to opt-in to these remote proxies from the People chain, would store the last X storage roots from the People chain. As the operation is async, it is better to keep track of multiple storage roots of the People chain to not require a timed inclusion of a transaction. On the other side it brings the downside of proxies staying longer valid on the remote chains, because the remote chains still keep X storage roots around. I think a reasonable time to keep the People storage roots around would be 10 minutes. This would mean from proof generation to transaction inclusion there are 10 minutes, which sounds reasonable to achieve.