I’ve come to the conclusion zk interaction with frames is going to be crucial. Particularly when payments are added to frames.

If the fid is known before a price is quoted, then it’s actually quite easy to charge more based on activity.

Many ways, but I can check onchain spending habits and adjust accordingly.

Working on building zkTLS infra/products. A ruthless empiricist and meme connoisseur.

/opacity
/eulerlagrange

Generate a ZKP locally in a frame, get it verified and use the result to drive some business logic. Should be a lot of fun.

Founder, zCloak Network. 
https://zcloak.network
https://cloakinglayer.com

The hard part is proving the signer is a valid eddsa. The state is stored in a contract on OP.

working on blockchain privacy

https://joshcrites.com

Yes, they would need to. Keep in mind the protocol is all about client diversity. Warp wouldn’t add it unless it was fast, and it added value.

The issue with zkFrames is proving:

1. Eddsa signer is valid (evm proof)
2. Fid replay protection

Doing all of this fast isn’t a simple thing. Needs discussion.

Wouldn't warpcast also have to change client side code to allow for zkp generation? Frames are just basic http requests right now