cc: @Chris-Hibbert

In VaultFactory, we pass parameters called directorParamOverrides and managerParams via privateArgs. The first is then passed to makeParamManagerFromTerms to override the values originally passed in terms. The second is passed through to provideVaultParamManagers, where it's processed as managerParamOverrides. Use either of those as the model here.

Further analysis is needed to assess potential risks or disruptions this might cause

I think the EC has not changed the value of this parameter in the running contract. That means, this time around, that resetting the value to its default wouldn't have any effect. We still want to set up the upgradable code so that if the EC does change it, the new value stays set through any subsequent upgrade.

To ensure that , after the contract upgrade, the provisionPool public facet exposes the same methods as it did in the previous incarnation, I included all method declared in the publicMixinAPI methodGuard.

However, I am reconsidering whether it makes sense to include all these methods—particularly those declared in typedAccessors. These methods might not be required by the contracts that consume the provisionPool public facet, potentially adding unnecessary complexity or "noise" to the interface.

Question:
Should all methods, including those from typedAccessors, remain exposed in the provisionPool public facet?

As part of the core-eval proposal required to upgrade provisionPool, we need to fetch the current value of the governed parameter, specifically PerAccountInitialAmount. This value must be included in the privateArgs to ensure it is overridden and does not reset to the default value during the upgrade.

From what I understand, we have two methods from the provisionPool public facet that can be used for retrieving the PerAccountInitialAmount value:

• getSubscription
• getGovernedParams

Question:
Is there a preferred method for fetching this value? If so, what is the rationale?

Question:
Should all methods, including those from typedAccessors, remain exposed in the provisionPool public facet?

Definitely not necessary. You do have to check existing code to ensure that anything that will get called remains, but if all callers will be updated with the upgrade, it's fine to drop methods that won't be used going forward. If there might be UIs or other tools that use the methods, you have to tread very carefully. Usually with two separately-release tools, you have to do a multi-release dance to remove usages from the caller before reming them from the service.

Question:
Is there a preferred method for fetching this value? If so, what is the rationale?

We've used both methods in various places when one or the other was blocked or recalcitrant. I would say that looking them up from governance is more general, and more likely to be the common path that works consistently for most upgrades.