meetm

@meetm.eth

56 Following

26 Followers

meetm pfp

Very barebones implementation of `fit`(forge interactive tracer). I got tired of working with some very huge traces and collapsability would have been very nice to have. [GIF in quoted tweet]. https://twitter.com/meetmangukiya98/status/1781229188365885472

0 reply

0 recast

0 reaction

meetm pfp

are there any AA wallet in production that supports passkeys?

0 reply

0 recast

1 reaction

meetm pfp

https://twitter.com/meetmangukiya98/status/1732314077131866289

0 reply

1 recast

0 reaction

meetm pfp

https://twitter.com/meetmangukiya98/status/1732314077131866289

0 reply

1 recast

0 reaction

meetm pfp

is there no gifs or vids attachment support on farcaster?

1 reply

0 recast

0 reaction

meetm pfp

any website/feed of newly created contracts?

2 replies

0 recast

0 reaction

meetm pfp

Rug pullers can set signers as such and market it as secured by deploying a safe with only vitalik as owner or something.

0 reply

0 recast

1 reaction

meetm pfp

Yeah. This is only a problem if people start seeing the guards as some kind of guarantees. Like in case of treasuries there can be signers that don't show up on owner count but got set by direct write to the owner map. And users thinking trusting it to be a safe treasury seeing owners or modules on the UI.

1 reply

0 recast

1 reaction

meetm pfp

even if there was some opcode that provided you with list of storage slot diffs you still cant tell if a particular slot was a module mapping slot because of the slot being a hash of the key, etc.

0 reply

0 recast

1 reaction

meetm pfp

what slots would you check? how many slots would you check? they can be anything

2 replies

0 recast

1 reaction

meetm pfp

``` contract X { fallback() { assembly { sstore(MODULE_SLOT, module) } } } ```

0 reply

0 recast

0 reaction

meetm pfp

you cant. consider a delegatecall to a contract X. the guard wont see it as a `enableModule` transaction so it will let it pass. and this will set the modules[module] slot. https://github.com/safe-global/safe-contracts/blob/main/contracts/base/ModuleManager.sol#L89 essentially making it a module.

2 replies

0 recast

0 reaction

meetm pfp

direct storage writes to mapping slots from delegatecalls are still not protected against and will never be until delegatecalls are turned off completely

1 reply

0 recast

1 reaction

meetm pfp

checking now though it seems like next version of safe will execute guards even on module transactions https://github.com/safe-global/safe-contracts/commit/426e965d6533e1d1e9a2cc8830cdfa1b868a08da

1 reply

0 recast

1 reaction

meetm pfp

best you can do is add a guard before any modules are added and prevent adding modules with the guard thereafter. but even then there is no way for guard to know if no modules existed previously by direct storage write to the module slot

1 reply

0 recast

1 reaction

meetm pfp

but yeah its hard to guarantee anything on a safe as long as delegatecalls exist

1 reply

0 recast

1 reaction

meetm pfp

1 reply

0 recast

1 reaction

meetm pfp

Looking at the gate seems like owners can get out of sync if no one synced it after the hats was revoked?

1 reply

0 recast

0 reaction

meetm pfp

Not particularly familiar with zodiac. But guards don't execute on module transactions.

1 reply

0 recast

0 reaction

meetm pfp

Hard to restrict anything and cover all tracks as long as it has modules and delegate calls. First step would be to strip those out.

2 replies

0 recast

3 reactions