orenyodfat
orenyodfat
hey @zachferland any update ? we are currently using 3box 1.22.2 and here is the dependency logs ├─┬ [email protected] │ ├─┬ [email protected] │ │ └─┬ [email protected] │ │ └── [email protected]...
this already been done on v2. adding that to v1 is a bit complex and need to be discussed when and how.
user should choose if the call should be as an admin to the proxy contract or to the real implementation contract. for the later Alchemy should fetch the implementation Abis...
this was partly solved with a workaround for dxdao current mcgs . by https://github.com/daostack/alchemy/pull/2413 issue is still valid , as there is a need for generic solution.
no it does not work :(
does this is valid from AdminUpgradeabilityProxy which are deployed from other contracts ? e.g via app.sol https://github.com/OpenZeppelin/openzeppelin-sdk/blob/master/packages/lib/contracts/application/App.sol#L117 @abcoathup @spalladino
@AugustoL could you please explain more about the motivation behind this scheme . In relation to security concerns : - This scheme has no constraint re the target contract it...
> > @AugustoL could you please explain more about the motivation behind this scheme . > > In relation to security concerns : > > > > * This scheme...
> > Why is this contract name prefixed with "dxDao"? Does it have no possible more widespread use? > > yeah, right? I guess the idea is to have this...
Thanks @mudgen for bringing this up! Using the Diamond standard for (or part of ) a dao sound interesting. We will evaluate this option and take it into consideration for...