Contract-embeddable library for managed parameters (Governance) #3186
Comments
Chris-Hibbert
added
enhancement
|
Just thinking out loud here. A Parameter would be some value, usually something that could pass throug E Data guard unscathed, that could only changed by goverence. Boiling it down, it sounds like an E's VarSlot with a readonly facet and a readwrite facet. The former facet is held by the smart contract and does not need to be closely held. The latter facet is held by whatever governance mechanism used. Where would the aforesaid VarSlots live? most likely in the vat running the smart contract being parameterized but it would not be out of the question that they live elsewhere. (An example would be akin to LIBOR rate etc) Most likely one smart contract would have (quite) a few Parameters so it is prudent of having some sort of parameters manager or some such that takes in readonly VarSlot facets, assigns a petname to each and provides an accessor function/closure of the form param('') to be used inside the smart contract's code. (It could also be a proxy to allow for param.rate or such usage) On the right track here or at least close? |
We expect to usually put it in the managed contract so access to it is a synchronous operation. We'd rather the updates to the parameters be async than accesses. Our expectation is that these parameters are specific to each contract and don't need to be shared or widely accessible. There may be a few or several, but we won't necessarily know at the start which ones governance will want to change. So we'll add as many as plausible for the contracts we want to manage. The larger task here is building the governance system that would be able to hold the management facet and change the parameters after a vote or other management decision. |
closes #3186 outstanding issues: * should this validate types? * is there a clean way to assert something is an amount? * should managed amounts (and ratios) only set the value and leave the brand to the managed contract? * are there others types to add or remove?
closes #3186 outstanding issues: * should this validate types? * is there a clean way to assert something is an amount? * should managed amounts (and ratios) only set the value and leave the brand to the managed contract? * are there others types to add or remove?
closes #3186 outstanding issues: * should this validate types? * is there a clean way to assert something is an amount? * should managed amounts (and ratios) only set the value and leave the brand to the managed contract? * are there others types to add or remove?
|
Rather than having governable params be entries in a map, conceptually, have them be discrete, typed cellsl e.g., and then usage would be |
closes #3186 outstanding issues: * should this validate types? * is there a clean way to assert something is an amount? * should managed amounts (and ratios) only set the value and leave the brand to the managed contract? * are there others types to add or remove?
closes #3186 outstanding issues: * should this validate types? * is there a clean way to assert something is an amount? * should managed amounts (and ratios) only set the value and leave the brand to the managed contract? * are there others types to add or remove?
* feat: manage parameters for a contract closes #3186 outstanding issues: * should this validate types? * is there a clean way to assert something is an amount? * should managed amounts (and ratios) only set the value and leave the brand to the managed contract? * are there others types to add or remove? * chore: convert functions to arrow functions * chore: add types for handle and any. * chore: drop an inadvertant import * feat: add lookup for param names and details * chore: update version info * chore: review suggestions dependency reduction support instance and installation rather than handle support NAT type which must be a bigint rename publicFacet to params * refactor: paramManager separates each param updater change 'any' to 'unknown' drop an unneeded guard clause a single getParams() describes all parameters * chore: typescript corrections Thanks to Michael Fig. * chore: review cleanups dependency trimming better test for AMOUNT. improve some error messages narrow some type declarations add tests for INSTANCE and INSTALLATION * chore: correct esm import
closes #3186 outstanding issues: * should this validate types? * is there a clean way to assert something is an amount? * should managed amounts (and ratios) only set the value and leave the brand to the managed contract? * are there others types to add or remove?
closes #3186 outstanding issues: * should this validate types? * is there a clean way to assert something is an amount? * should managed amounts (and ratios) only set the value and leave the brand to the managed contract? * are there others types to add or remove?
closes #3186 outstanding issues: * should this validate types? * is there a clean way to assert something is an amount? * should managed amounts (and ratios) only set the value and leave the brand to the managed contract? * are there others types to add or remove?
closes #3186 outstanding issues: * should this validate types? * is there a clean way to assert something is an amount? * should managed amounts (and ratios) only set the value and leave the brand to the managed contract? * are there others types to add or remove?
What is the Problem Being Solved?
Part of Governance Epic
Build a library that can be embedded in Zoe contracts to manage parameter values that can be set from outside by governance.
It should be data driven as much as possible.
The text was updated successfully, but these errors were encountered: