Consider abstracting balances from different actors in a single vault

[ggonzalez94]

Originally proposed here

The idea is that instead of tracking balances and allowing deposit/withdraw on individual contracts, we create a NativeVault (I guess a similar mechanism for ERC20s) that holds all funds for proposers, provers and other actors of the rollup(not to be confused with user balances, that is a very different conversation).

This is only beneficial if we have more than one contract where the same actor(s) need to deposit/withdraw some since it isolates the logic and make it more capital efficient. At the time of writing this, the only contract with these requirements is the ProverManager.

[xiaodino]

I like this idea and would be happy to help contribute. I have a few questions

Access Control:
Do we envision NativeVault enforcing permissions directly (e.g., only ProverManager can slash or withdraw prover funds), or should it rely entirely on calling contracts for authorization? Understanding clearly where responsibility for enforcing permissions sits would be very helpful.

Future Scalability:
Looking ahead, if we introduce more roles or modules (like proposers or preconfirmation registries), would each of these modules inherit their own NativeVault, or might it eventually be beneficial to consolidate ETH accounting into one shared contract across modules? I’m curious about the intended long-term architecture and how we anticipate managing this as complexity grows.

Happy to help prototype or implement.

[nikeshnazareth]

The idea is that instead of tracking balances and allowing deposit/withdraw on individual contracts, we create a NativeVault (I guess a similar mechanism for ERC20s) that holds all funds for proposers

This is only beneficial if we have more than one contract where the same actor(s) need to deposit/withdraw

If I understand correctly, Ernesto's idea was not about creating a separate vault contract to hold the funds independently, but about encapsulating the vault logic in its own abstract contract and letting the prover manager inherit it. I'm generally in favour of all versions of encapsulating related logic in a self-contained abstraction, whether or not we actually end up reusing it.