# Random 4337 Thoughts ## Left of Launch: Pre Transaction workflows, authentication, and other - [EIP-6662: AA Account Metadata for Authentication](https://ethereum-magicians.org/t/eip-6662-aa-account-metadata-for-authentication/13232/1) - EIP posted 8 days ago w/o much traction but fruitful to think through - ERC 4337 extension "to store authentication data on-chain to support a more user-friendly authentication model" - TLDR; smart contract accounts can store URLs of "autheticators" that can authorize transactions on their behalf ![](https://hackmd.io/_uploads/Syn-cw1g3.png) ## Post Auth: how the intent pool changes things - Im not sure it does except for adds extra hoops for searchers and block builders. ## Filler networks: how filler networks change the supply chain - Technically this seems feasible, potentially even easier with userops. - callData is the easy part of this, it specifies the requirements of the trade like normal with maybe some extra guard rails ( slippage less than x and price doesnt differ less than y) - ***Question?*** : how to ensure "filler" gave the best price - could potentially require bonding and then retroactively slash based on a validity proof. "filled tx" would still be stealable so can't go in public mempool - at least unencrypted (dkg + encrypt to random subset?). - authorization/verification of a user op can be a snark, so this could hypothetically encapsulate a proof from a "filler network" or "filler" that this is the best price possible. But this proof is highly reliant upon the not-yet-canonical pending block, a liquidity injection prior to trading can change things drastically. A filler could also potentially offer JIT-as-a-service, so the proof likes something like "if i were to inject XYZ at this range it would still be more stale than a p2p trade so u get a p2p trade m'am/sir". - **MEV Supply Chain** : tx data/user op must be sent privately. With a couple modifications to the spec I believe you could do this on the bundler network, but the 4337 DoS protection goes out the window(i.e. simulating verification step). But if the auth is a snark u could actually prove that the execution is valid on some block X....🤔 - In "Optimal Routing in CFMMs" there is an assumption about top of block execution since you dont have unknown perturbations to the underlying pools. A filler would need to be guranteed top of the block.