You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Often DAOs have a technical committee that is responsible for certain contracts and working with them. It would be wise to be able to set up a separate policy for cross-contract calls for specific contracts (and potentially for specific methods of these contracts), so such proposals are not disturbing the rest of the councils.
For example:
The DAO of the project has 20 councils. There is a DeFi committee that is responsible for liquidity of the project token. DeFi committee of the DAO consists of 3 DAO Councils. The vote 2 of 3 of them is enough to access ref.finance contracts on behalf of the DAO.
The text was updated successfully, but these errors were encountered:
Thanks for making this report. An immediate work around would be to use multiple DAOs. Following your example, you'd have a project-defi.sputnik-dao.near and project-deploy.sputnik-dao.near. Each DAO would have it's own authorization access keys and whitelist permissions for external contracts like ref.finance.
Often DAOs have a technical committee that is responsible for certain contracts and working with them. It would be wise to be able to set up a separate policy for cross-contract calls for specific contracts (and potentially for specific methods of these contracts), so such proposals are not disturbing the rest of the councils.
For example:
The DAO of the project has 20 councils. There is a DeFi committee that is responsible for liquidity of the project token. DeFi committee of the DAO consists of 3 DAO Councils. The vote 2 of 3 of them is enough to access ref.finance contracts on behalf of the DAO.
The text was updated successfully, but these errors were encountered: