---
# System prepended metadata

title: Random 4337 Thoughts

---

# 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.