ERC-6900: Modular Smart Contract Accounts and Plugins

fmc · May 26, 2023, 5:30pm

Very happy to hear about the pivot from delegatecall to call.
Can’t wait get my hands dirty with the Plugin Storage lib!
Meanwhile, msged you on Telegram regarding contributing to the proposal.

in2xx · May 31, 2023, 8:56am

Thanks @adamegyed for worth proposition!
This standardization of modular architecture is a very important proposition, given the variety of wallet providers that will enter the wallet market in the future.

BACKGROUND
We’re building a borrow/lend application that requests to prohibit execution transfer() and related modules, setApprovalForAll(), approve() and burn() methods to borrower’s wallet.

Those prohibit logic was implement into Safe’s guard contract so that borrower doesn’t be required to deploy each app-specific contract wallets but they are only required to apply guard to their wallet.

At ETHGlobal Istanbul, Pinky team also built an application which implement prohibited logic into guard contract.
If the each application provide own “app-specific” wallet, Users has to deploy each wallet that they want to use.

Following above, I could say that, from application developer side of view, this topic is much important for usability and account based identity contexts.

I draw a shape of composability like below (from this tweet).

STATUS QUO
The safe’s guard can be bypassed by module logic and this issue was flagged couple years ago and Safe V2 will implement “global guard” (details are unknown).

github.com/safe-global/safe-contracts

Allow to set a transaction guard for each enabled module

opened 07:37PM - 20 Aug 21 UTC

auryn-macmillan

enhancement

## Context / issue Transaction guards are a really powerful feature for the G…nosis Safe, but they are currently limited only to multisig transactions. Any installed modules circumvent an enabled transaction guard. If a user would like to implement similar logic for a module, they would need to implement it either as part of their module or as a modifier module that sits between their module and the safe. ## Proposed solution Allow users to optionally enable a guard for each enabled module. This would allow each enabled module to have distinct pre and/or post-checks that it must pass each time it time it attempts to execute a proposal. ## Alternatives The alternative is to build this logic directly into modules or as a modifier module that sits between enabled modules and the safe. In either case, this would mean duplicating code to enable similar guard functionality for module and multisig transactions. ## Additional context If this is implemented, we can create a `IGuardable.sol` interface in Zodiac and encourage the DAO community to build more compatible transaction guards.

IMO, the reason why they didn’t support it at V1 that the Safe designed their architecture for organizations who is motivated to manage treasury by Multi-Sig so module would be setup by member of HQ, not setup by outside application.

OPINION
So, standing to above problem, I think the global preHook also need to implement logic below:

With Opt-In, global preHook enables applications to prohibit transactions to wallet user.
User can’t disable global preHook without application permission.
*In case of our application, if borrower will return NFT from their wallet, wallet user could disable global preHook.

When updatePlugins is called with PluginAction.REPLACE or PluginAction.REMOVE, the calls MUST be validated by preHook and postHook.

   function updatePlugins(PluginUpdate[] memory pluginUpdates, address init, bytes calldata callData) external;
   function updateGlobalPlugins(GlobalPluginUpdate[] memory globalPluginUpdates, address init, bytes calldata callData)
       external;