0

I am reading a lot of documentations and source code about Safe and its ecosystem. My goal is to use this protocol for an upcoming hackathon project.

From my understanding, a guard can be set up (and removed) by the user to add additional checks before or after a transaction. I want to know if it is possible to enforce the use of a guard for a limited time, before allowing the user to remove it?

I want to do that to allow people to use a feature of my project that requires a monitoring of the transactions made by the user. Basically, the user will add the guard to its Safe wallet to access the feature, and should be able to take the guard off of its wallet after a given duration (1 month for example). Is it possible to do that without modifying the existing Safe code?

My guess is that the Guard could prevent the Safe wallet itself from calling GuardManager.setGuard() through the GuardManager.checkTransaction() call made by the wallet, but for that to happens the wallet should always call GuardManager.setGuard() through its Safe.execTransaction() method. I wonder if the FallbackManager class could allow one to bypass the Guard checks, by adding a new fallback method that would call GuardManager.setGuard()?

2
  • You can include the expiry logic in the guard itself
    – mikheevm
    May 3, 2023 at 13:09
  • @mikheevm You are right, I figured out that I can conditionally skip the guard checks directly in the GuardManager.checkTransaction() function. However, my concern is that I want the user to be unable to remove the guard once it is set, for a given amount of time. I guess the GuardManager.setGuard() function can be catched and forbidden by the Guard itself, but does the FallbackManager could allow the user to bypass this security?
    – BipBop
    May 3, 2023 at 13:59

1 Answer 1

0

The Safe singleton contract inherits the FallbackManager contract, and no function can be added to the FallbackManager class without migrating the Safe to a new singleton. Theoretically, one could workaround the guard by adding a new module or executing a delegatecall transaction. Your guard should take this kind of transaction into account too.

1
  • Thank you for your answer. It is true that a new module will be able to bypass the Guard, and although I fail to understand why the modules doesn't use the Guard checks, I definitely need to take that into account. The module could either execute any logic I try to prevent, or delegatecall to GuardManager.setGuard() to remove my security. I will try to think of a solution around that!
    – BipBop
    May 3, 2023 at 16:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.