Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
using governedContractKits in core eval replacing committee and chart…
…er (#10178) <!-- < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < ☺ v ✰ Thanks for creating a PR! ✰ ☺ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --> <!-- Most PRs should close a specific Issue. All PRs should at least reference one or more Issues. Edit and/or delete the following lines as appropriate (note: you don't need both `refs` and `closes` for the same one): --> refs: #10134 #10133 ## Description This pull request builds on #10166 and #10164. It updates the core eval code to utilize the `governorCreatorFacet` for the governed contracts via the `governedContractKit`. Initially, the aim was to use the `governedContractKit` to access facets from price feed contracts. But since it also includes facets for other governed contracts, I expanded the code to incorporate these as well. ### Security Considerations Same as #10166 and #10164 ### Scaling Considerations <!-- Does this change require or encourage significant increase in consumption of CPU cycles, RAM, on-chain storage, message exchanges, or other scarce resources? If so, can that be prevented or mitigated? --> ### Documentation Considerations <!-- Give our docs folks some hints about what needs to be described to downstream users. Backwards compatibility: what happens to existing data or deployments when this code is shipped? Do we need to instruct users to do something to upgrade their saved data? If there is no upgrade path possible, how bad will that be for users? --> ### Testing Considerations Same as specified in #10164 ### Upgrade Considerations <!-- What aspects of this PR are relevant to upgrading live production systems, and how should they be addressed? -->
- Loading branch information