Manage bridged tokens on a large number of chains

# Introduction The new [ERC-7281](https://ethereum-magicians.org/t/erc-7281-sovereign-bridged-tokens/14979) proposes a way for token sovereignty. The party responsible for a token creates a copy for this token on each (relevant) chain: a xERC-20 token or xToken for short. All legacy versions of the tokens (on any chain where a legacy version is present) can be wrapped via a lockbox into the new xToken. Then the party authorizes bridges to burn and mint these xTokens. The burning and minting can be throttled to manage (bridging) risk. I think this is a good idea because it makes bridged tokens fungible while also managing risks of bridge hacks. Additionally, it removes the need for liquidity pools to convert bridged tokens into valuable/usable tokens. # Handling of xTokens The approach of [ERC-7281](https://ethereum-magicians.org/t/erc-7281-sovereign-bridged-tokens/14979) assigns extra tasks to the parties responsible for tokens, which frequently are DAOs. These parties should be aware of this and perhaps increase the number of involved participants to be able to handle the extra workload. Chains and bridges could facilitate this by sponsering several of the actions. Additionally third parties might offer services to help with these tasks. ## Tasks for parties responsible for tokens Here is a list of tasks that should be performed. As this is quite extensive and probably not even exhaustive, it will be a major effort. * Include xToken functions (for new tokens) * Extend xToken for non standard token functions * Adjust xToken for non standard chain features * Upgrade/update xToken in case of security issues * Security review of (updates on) xTokens * Choose xToken name, address, decimals * Deploy secure account (e.g multisig) everywhere * Deploy/update xToken everywhere * Deploy on new chains, taking into account non standard chain features * Update custom xToken parameters everywhere * Pause xTokens in case of security issues * Synchronize updates/upgrades to prevent race conditions * Pay for deployment and updates/upgrades * Keep/update list of xToken addresses * Broadcast the updates to other parties * Get all defi protocols, centralized exchanges to use the xTokens * Keep overview of amounts of xTokens per chain * Decide the trustworthiness of bridges and bridge aggregators, without discriminating bridges * Configure mint/burn parameters for all bridges * Update mint/burn parameters for all bridges * Add new bridges and remove obsolete bridges * Add new chains and remove obsolete chains * Detect bridge bugs / hacks and reductions in trustworthiness * Detect chain bugs / hacks * Lock tokens in LockBox * Follow up on legal enforcement actions ## Events The tasks can be linked to events that happen. Below is a list of relevant events. Taking into account the speed in which the token/bridge/chain world moves, the number of daily events will be large. * Inital creation of xToken for existing tokens * New token * New token with non standard token functions without xToken template * Obsolete token/xToken * Bug / security issue in a xToken or a LockBox * Parameter change for token/xToken * Upgrade of a xToken * Increased demand for xToken on specific chains * New bridge * Obsolete bridge * New bridge that isn't (yet) allowed to use mint/burn of xToken * Security issue in a bridge * Increase/decrease trustworthiness of a bridge * New chain * New chain with non standard features (instructions not supported) * Obsolete chain * Security issue in a chain ## Registrations required To be able to do all the tasks, it would be helpful to have the registrations below. If they aren't present, each party responsible for a token would have to replicate this. For other parties in the space, like users, defi protocols, centralized exchanges it would be difficult to track everything. * All xTokens * All bridges and bridge aggregators * All chains * Addresses of all xTokens on all chains * Flag spam xTokens on all chains * Trustworthiness of bridges * Incidents with xTokens, bridges, chains # Conclusion Most of the attention points in this document are relevant with or without [ERC-7281](https://ethereum-magicians.org/t/erc-7281-sovereign-bridged-tokens/14979). It illustrates a lot has to be done to fully support a large number of chains. Addressing these issues will help to adopt [ERC-7281](https://ethereum-magicians.org/t/erc-7281-sovereign-bridged-tokens/14979).