XToken v4, an invariant entry contract for users to choose which bridge: (custodian_dapp, source_token, target_token)

[hackfisher]

XToken bridge will be defined by a three-element tuple: (custodian_dapp, source_token, target_token).

custodian_dapp consists of Backing contract(source chain) and Issuing contract(target chain). Its functions include the following parts:

• Configure the message port that the bridge should use, This is crucial because Msgport choice is fundamental in ensuring the custodian's security.
• Security and inspection strategies (KYC, Guard, Safebox, rescue, recovery, token whitelist etc)
• Backing contract of the source chain: IXTokenBacking.sol. Removing the token update/register function.
• Issuing contract of the target chain: IXTokenIssuing.sol. Removing the token update/register function.
• Optionally, custodian_dapp can choose to provide a standard target_token template and util for user to create the target_token and set the mint auth to the custodian_dapp's Issuing contract

xToken can offer an invariant entry contract(without owner and proxy) across each chain, allowing users and UI interfaces to select the bridge tuple that best suits their needs, it will provide interfaces for custodian_dapp to implement, custodian_dapp must follow these xToken interfaces for being able to used by users via xToken entry contract.

In this way, It becomes permissionless, granting users the freedom to choose any custodian they prefer for their bridge.

[hackfisher]

In xToken v3, source_token and target_token are normally managed by custodian_dapp, but actually they can be decoupled. In the cases of rollup bridges we learn from, such as Arbitrum and Optimism, Arbitrum DAO are acting as the custodian for all the assets bridged to Arbitrum One. Some parties might be professional or fit for custodian, not necessarily being related to the deployer of source_token or target_token. This is why we decouple source_token and target_token from custodian_dapp.

Why introduce an invariant xToken entry contract? As now, they might be many/various custodian_dapp existing, and if not specialized, most of them could serve arbitrary tokens. By providing xToken entry contract (or even UI ), various custodian_dapp can be presented as options to be chose by (merchant) users when they bridge.