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

Add support to Staking contract to separate operational from financial capabilities #358

Open
peterargue opened this issue Mar 15, 2023 · 4 comments
Assignees
Labels
enhancement New feature or request Feature Feedback good first issue Good for newcomers SC-Eng Issues that we want to see surfaced in SC-Eng ZH Board

Comments

@peterargue
Copy link

peterargue commented Mar 15, 2023

Issue To Be Solved

Currently, a single capability is used by node operators to interact with the Staking contract for all updates, including updating the node's hostname, staking/unstaking, and removing funds. This works fine for small or individual operators, but adds risk for larger operators that may have a team/automations that help manage their nodes.

Suggest A Solution

Instead of a single capability, create 2 or more separate capabilities that handle each of the types of accesses. For example, it could be broken down in the following way

  1. Operational access - used to update the node's hostname and any other strictly operational changes. Operators could give access to this to an automated system or a team of operators
  2. Staking/unstaking - used to commit new tokens, unstake tokens, or restake rewards, etc. All financial operations that don't involve withdrawing funds. This could be granted to a small number of highly trusted individuals to allow managing their fleet.
  3. Withdrawing funds - used to withdraw unstaked funds. This would be kept securely in an HSM or cold storage with very restricted access.

By default, all 3 capabilities would be added to the node's staking account, but the operator would have the option to move/delegate them to different accounts.

@joshuahannan
Copy link
Member

Made a small edit to your proposal to the second capability. This makes sense.

One question: I assume that most node operators and delegators are using the staking collection, so I am think that we just make these three new interfaces for the staking collection contract, or do you think we need to add the interfaces to both the core staking contract and the staking collection?

@peterargue
Copy link
Author

I don't have a strong opinion on that. I think as long as there's a way for operators to delegate permission for each of those capabilities (particularly 1 & 2), either should be fine. Is it simple to switch to using the collection if you're currently using the core staking contract?

@joshuahannan
Copy link
Member

yes, this transaction updates any account to use the staking collection, even if they are already using a different setup:
https://github.com/onflow/flow-core-contracts/blob/master/transactions/stakingCollection/setup_staking_collection.cdc

@joshuahannan joshuahannan added enhancement New feature or request good first issue Good for newcomers SC-Eng Issues that we want to see surfaced in SC-Eng ZH Board labels Mar 20, 2023
@joshuahannan joshuahannan self-assigned this Aug 23, 2023
@joshuahannan
Copy link
Member

I think the stable cadence upgrade would be a perfect place to introduce this feature since it is a great use case for entitlements. I'll try to get it added to the feature branch relatively soon

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request Feature Feedback good first issue Good for newcomers SC-Eng Issues that we want to see surfaced in SC-Eng ZH Board
Projects
Status: 🧊 Backlog
Development

No branches or pull requests

2 participants