Design: Token master list contract

[alexprate]

Q: What is the best way to manage the configuration of this contract in a context of decentralised exponential growth network? Should we create a unified token master list contract, including Rainbow, Seeds and Hypha network native tokens? Or one list for Seeds and one for Hypha?

Challenge 1: The rainbow token master list can specify the use case - as in the dApp that needs to display the token. How and who will have authority to add a token in the master list? How new dApps register to be able to display their own token?

Challenge 2: Will communities using the DHO and Seeds create a native token + a rainbow Seeds? Or will they use one token across the board. How would the DHO then display this token? Integrate with the rainbow token master list?

A side question is: how will the multi-tenant native tokens be managed in the DHO? Will we have a contract similar to the rainbow contract and rainbow master list?

Note that this challenge will also be great in a multi-chains environment.

[alexprate]

@n13 As agreed yesterday, we will use the rainbow token master list for now. These challenges will occur in the future but it is premature to address them now. Closing this task for now.

[chuck-h]

This use of "rainbow" terminology is confusing: the token master list contract provides a standalone metadata storage function that is not directly tied to the Rainbow token contract which provides tokens. So I would say "token master list" instead of "rainbow token master list".