Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow 3rd parties to register new token networks #1416

Closed
karlb opened this issue Nov 9, 2020 · 4 comments · Fixed by #1492
Closed

Allow 3rd parties to register new token networks #1416

karlb opened this issue Nov 9, 2020 · 4 comments · Fixed by #1492
Assignees
Milestone

Comments

@karlb
Copy link
Contributor

karlb commented Nov 9, 2020

Currently, we limit the number of token networks and register the full number of allowed tokens at deployment time. We would like to open up the registration of additional token networks to 3rd parties.

Who can register a token network?

Potential solutions:

  • Everyone (problems see below)
  • Parties whitelisted in the contracts
  • Parties chosen by some DAO

Problems with allowing anyone to register

Currently, we only allow a single token network per token and the one registering the network can set some settings at that time. This brings the risk of having bad settings for a token network without a way of changing the settings or using a different token network for that token.

Potential solutions:

  • Don't allow any settings (chosen solution)
  • Limit set of potential registrars to people choosing good values
  • Allow multiple networks per token

Available settings:

  • channel_participant_deposit_limit
  • token_network_deposit_limit
  • settlement_timeout_min (currently fixed to value set in registry)
  • settlement_timeout_max (currently fixed to value set in registry)
  • deprecation_executor (currently fixed to value set in registry)

If we removed the deposit limits and kept the other values fixed to the one in the registry, no settings would be left when registering a token network. This would allow us to go with the solution "Don't allow any settings".

@GataKamsky @czepluch

@czepluch
Copy link
Contributor

czepluch commented Nov 9, 2020

Yeah, the deposits is another thing to think about, but I assume they will also be removed at some point.

@karlb karlb added this to the Coruscant milestone Dec 15, 2020
@palango
Copy link
Contributor

palango commented Feb 19, 2021

@GataKamsky I agree with Karl in that removing the limits and using fixed settings from the registry would be the easiest way to accomplish this. It would also reduce the code size and potentially help with issues related to that issue.

What do we need to push this forward?

@palango palango self-assigned this Feb 19, 2021
@palango
Copy link
Contributor

palango commented Mar 1, 2021

We'll not do this at this point in time. More infos in https://github.com/raiden-network/team/issues/924

@GataKamsky
Copy link

I agree with the proposal made by @karlb.

@karlb karlb self-assigned this Jul 22, 2021
karlb added a commit to karlb/raiden-contracts that referenced this issue Jul 22, 2021
We want the limit removal to be completely done once we do it. When new
TN are deployed afterwards, they must be deployed without limits.

Closes raiden-network#1416
karlb added a commit to karlb/raiden-contracts that referenced this issue Jul 22, 2021
We want the limit removal to be completely done once we do it. When new
TN are deployed afterwards, they must be deployed without limits.

Closes raiden-network#1416
karlb added a commit to karlb/raiden-contracts that referenced this issue Jul 29, 2021
We want the limit removal to be completely done once we do it. When new
TN are deployed afterwards, they must be deployed without limits.

Closes raiden-network#1416
palango pushed a commit that referenced this issue Jul 29, 2021
We want the limit removal to be completely done once we do it. When new
TN are deployed afterwards, they must be deployed without limits.

Closes #1416
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants