AggLayer: investigate whether the `AggLayerFaucet` accounts should be `Ownable2Step`

[mmagician]

We don't expect the owner to change, and having this possibility of rotating faucet's owner might be a bug

[bobbinth]

I think there could be a number of reasons why we may want to rotate the owner. For example, we discover that there is a bug in the implementation of the owner's code (e.g., an issue with the multisig).

As an alternative, we could consider modifying Ownable2Step to add the functionality for "freezing the owner". This way, an account could start out Ownable2Step with owner rotation capabilities, and at a later point could decided that owner rotation is not needed any more.

[mmagician]

The problem with 2-step ownership model is that the bridge can't "accept" ownership (we could add such support probably but IMO that's going to only complicate things)

[bobbinth]

Ah - I misread this issue. I thought this was about the bridge account implementing Ownable2Step but this is about the faucet accounts. For the faucet, I think it may make sense to simplify the ownership model, though, I haven't thought too much about this yet.

[PhilippGackstatter]

What is the functionality that the agglayer faucet needs? Does it need an owner? If not, it could use ownable2step initially and then call renounce_ownership, but I'm probably missing some context.

[mmagician]

On the faucet, we authenticate that MINT or BURN notes are sent by the owner (the bridge), so it does need to have one set.

[onurinanc]

So, I believe what would be a good solution to bring back the Ownable component that we've recently removed from the codebase.

[PhilippGackstatter]

So, I believe what would be a good solution to bring back the Ownable component that we've recently removed from the codebase.

Yes, but maybe we can revive it without the transfer ownership functionality, so it is a very simple static ownable component? For use cases that need ownership transfers, we still have Ownable2Step.