This week I built more documentation for fc devs at https://dtech.vision/farcaster/ and a Frames improvement protocol to include the chainId to make live easier for building TX Frames.

This week I built more documentation for fc devs at https://dtech.vision/farcaster/ and a Frames improvement protocol to include the chainId to make live easier for building TX Frames.

https://github.com/farcasterxyz/protocol/discussions/194

Developer 🤓 build, develop and operate Farcaster solutions @ dtech.vision also love tech, decentralization, fitness and oldschool rap 😎

cypherpunk wannabe, engineer working on @frames /open-frames /opencast
https://stephancill.co.za create stories at https://stories.steer.fun

the problem here is that chainId is only client side.

if you're frame server returns the chainId that state isn't passed to the post_url called after doing the TX

so you have to figure that out via
1) global state
2) in memory storage
3) DB
4) other

if it were part of the frame message, then frame servers don't need that complexity

But the chain ID is included in the tx data response - why would that tx be executed on a different chain?