Each confidential transfer happens synchronously with a before and after state. Subsequent transfers will read from this new state–be it in the same block or in a month. There is no issues with multiple transfers in the same block using ERC-7984.
Thank you for taking the time to clarify. I need to correct my earlier comment.
We had assumed ERC-7984 used a ZK-based design, and under that assumption we raised a concurrency concern. After re-reading the spec and the Zama implementation, it’s clear the reference implementation uses Fully Homomorphic Encryption (FHE), not zero-knowledge proofs. With FHE, transfers are homomorphic operations on ciphertexts, and sequential execution works as intended—each transfer sees the updated state from the previous one, so multiple transfers in the same block work correctly. Our concern was based on a wrong assumption about the underlying technology, and I apologize for the confusion.
We’re still learning the different privacy approaches in this space. Our VOSA protocol uses a ZK-based, UTXO-like model, which handles concurrency through independent one-time addresses rather than sequential state updates. It’s a different design choice, not a fix for something in ERC-7984. We’ll update our discussion post to remove the incorrect concurrency claim.
Thanks again for the clarification—it helped us understand ERC-7984 better, and we look forward to more exchanges like this.
1 Like
Really interesting, Im looking for a reference implementation, but couldn’t find any. The concept sound really interesting
After some introspection and work with the OpenZeppelin reference implementation I must agree that the two sets of transfer functions are unnecessary. I am for removing it in favor of simplicity.
1 Like
OpenZeppelin maintains a reference impl here.