Hello @cliffton.eth! Thank you very much for this proposal.
At SEEDGov, we had been researching how to help the DAO with this issue, so we would like to contribute to the discussion with part of this analysis.
The Committee Structure
At this point, we all agreed that a specialized committee was necessary. In our analysis, we considered a similarly structured committee, including an external contributor from the DAO with technical knowledge and communication skills to keep the DAO informed about developments in the Council. From our perspective, the proposed structure seems like a good option.
The current model in practice:
In the most recent token integrations into the native bridge, we experienced several delays until final implementation:
-
Register $BORING in the Arbitrum generic-custom gateway: Posted in the forum on May 13th, 2025, execution expected on August 25th, 2025. (104 days)
-
Sky Custom Gateway: Posted in the forum on March 3rd, 2025, executed in L1 on July 22nd, 2025 (141 days).
-
Upgrading RARI Governance Token on Arbitrum: Posted in the forum on August 5th, 2024, executed in L1 on October 31st, 2024 (87 days).
This means that reducing the delay to 30 or even 40 days is a big win compared to the current situation. Not to mention the fact that builders would have a clear and simplified path to include their tokens in the native bridge.
The Current Model in Theory
In the current governance process, we understand that there is a proposer who loads the payload, the vote is executed, and once approved, it is sent to the L2Timelock contract, where in cases like this involving a transaction (a message with instructions) from L2 to L1, there is an 8-day timelock before sending the message through the fraud proofs (7-day delay) and finally a 3-day timelock delay in the L1Timelock contract.
Now, the L2Timelock contract has the following roles:
- PROPOSER_ROLE
-
Function: They can propose actions to be executed after the timelock period
-
Who has it:
-
The Core Governor
-
The Security Council
-
-
- EXECUTOR_ROLE
-
Function: They can execute actions after the timelock expires
- Who has it: Anyone can execute (configured as public role)
-
CANCELLER_ROLE
-
Function: They can cancel pending proposals
-
Who has it:
-
The Core Governor
-
The Security Council
-
-
-
-
TIMELOCK_ADMIN_ROLE
-
Function: They can change the minimum timelock delay and manage roles
-
Who has it:
- The UpgradeExecutor (Governor)
-
-
In this case, what interests us is the proposer_role and the canceller_role which indicates who can cancel transactions. The L2Timelock allows adding more than one address to these roles.
In our analysis, we had considered two options:
Option 1: Direct Maintenance Committee Integration with L2 Timelock
Approach: Add the Maintenance Committee Multisig directly as a proposer to the L2 Core Timelock with a custom 20-day delay and restricted function scope.
Maintenance Committee Flow:
Maintenance Committee Multisig
↓ (20 days L2 timelock delay) - Here the DAO can Veto via on-chain vote
Modified L2 Timelock
↓ (8 days L2 timelock delay)
L2 Core Timelock
↓ (7 days L2→L1 message delay)
L2→L1 Message
↓ (3 days L1 timelock delay)
L1 Timelock
Total: 38 days
To make this possible, it would be necessary to modify the L2Timelock contract by admitting the committee to its proposer role, only for certain types of transactions and with a special Timelock, allowing the DAO to veto with a vote during “20 days” (number thought for the DAO to execute constitutional votes of 14-16 days)
This implies even modifying the original core L2Timelock contract so that it only accepts certain types of transactions from a specific proposer and that these transactions have a different delay than the rest, so from our perspective, it is the riskiest option.
This is where we have our first two questions regarding Tally’s proposal:
-
Is the Optimistic Governor Path designed as a separate module from the traditional Core Governor?
-
Would it be correct to assert that in this case, we are facing a similar situation regarding the proposer role? What we understand is that, whether we are dealing with a multisig (for example, similar to how the Security Council works, with the ability to propose and cancel proposals) or we are dealing with a separate governance module, it would be necessary for the L2Timelock to be updated to accept proposals and cancellations from new addresses with these roles.
These questions are important to understand the technical nature of these changes.
-
Are we building a new Governor Contract with different rules?
-
Are we modifying the existing Governor?
-
Is there a need to make additional changes to the L2Timelock?
-
If these last two questions are affirmative, don’t you think it’s a high risk to upgrade or modify any core governance contract, and requires deeper analysis? We raise this concern because Arbitrum has the largest TVL among L2s, and we must exercise caution when implementing these types of changes.
These are the questions we asked ourselves when investigating possible solutions, which is why we believe in the need to seek solutions that minimize any changes to the current core contracts and we believe that the best approach would be to create a WrappedL2Timelock as L2Timelock Proposer, with its own logic to accept, reject or dispute transactions related to maintenance/token listing tasks in the bridge.
Option 2: WrappedL2Timelock as L2 Timelock Proposer
Approach: Deploy the WrappedL2Timelock and add it as a proposer to the existing L2 Core Timelock, maintaining the original timelock’s integrity. The wrapper handles function restrictions internally, eliminating the need for core timelock modifications. Note: This option still requires granting the PROPOSER_ROLE to the WrappedL2Timelock in the L2 timelock, but does not require modifying the timelock contract itself.
Maintenance Committee Flow:
Maintenance Committee Multisig
↓ (20 days internal delay) - Here the DAO can Veto via on-chain vote
WrappedL2Timelock
↓ (8 days L2 timelock delay)
L2 Core Timelock
↓ (7 days L2→L1 message delay)
L2→L1 Message
↓ (3 days L1 timelock delay)
L1 Timelock
Total: 38 days
In this case, an external contract is created, with its own delay parameters, accepted transaction types, and possibility of veto via on-chain vote, as well as the possibility that the same Security Council that has veto power in the L2Timelock possesses the same ability in this external contract. In this way, the external contract would adhere to the same security standards as the L2Timelock itself, except for the Maintenance Committee Multisig. However, this approach doesn’t bring many advantages because it has the same 38-day delay as the previous approach.
Option 2B: WrappedL2Timelock with Dispute Mechanism (8-day delay + dispute)
Approach: Deploy the WrappedL2Timelock with a reduced 8-day delay and add a dispute mechanism that allows delegates with 5M+ ARB to trigger a dispute function plus constitutional vote. We believe this is the best approach:
Maintenance Committee Flow (No Dispute):
Maintenance Committee Multisig
↓ (8 days internal delay)
WrappedL2Timelock
↓ (8 days L2 timelock delay)
L2 Core Timelock
↓ (7 days L2→L1 message delay)
L2→L1 Message
↓ (3 days L1 timelock delay)
L1 Timelock
Total: 26 days
Maintenance Committee Flow (With Dispute):
Maintenance Committee Multisig
↓ (8 days internal delay)
WrappedL2Timelock
↓ (Delegate with 5M+ ARB disputes)
↓ (Transaction is stopped)
↓ (DAO constitutional vote)
↓ (If AGAINST veto: 8 days L2 timelock delay)
L2 Core Timelock
↓ (7 days L2→L1 message delay)
L2→L1 Message
↓ (3 days L1 timelock delay)
L1 Timelock
Total: > 43 days (depending on the results of the dispute)
Basically, the committee proposes a transaction to the WrappedL2Timelock, there is an 8-day window during which any delegate with more than 5M ARB can dispute the transaction and stop it (this is equal to the amount of ARB needed to propose a transaction in the governor). After this, the DAO has to vote to resolve the dispute, either by canceling the transaction proposed by the committee (in favor of the dispute) or allowing the transaction to be sent to the main L2Timelock. When a proposal is disputed, there is no set time because the WrappedL2Timelock contract waits for a resolution from the DAO to continue with the process. This allows greater flexibility and is not subject to arbitrary time limits.
In the future, this WrappedL2Timelock contract could be used to add new maintenance services. And the base security of the Core contracts will always be maintained.
Note: Governance should be the owner of this contract and be able to update it, change roles, revoke them, and change the delay time.
Some final considerations
What we notice with the scheme proposed by Tally is that, while it simplifies the current process, we still always depend on a vote that, while optimistic, is necessary with every action we want to perform. Regarding the vote itself, we have some observations to make:
We understand that by definition, these transactions remain as constitutional proposals, since there are protocol modifications that involve sending an L2 to L1 message, as is the case with protocols that want to whitelist their tokens in the native bridge and have to follow the process and constitutional quorum. It wouldn’t be bad if it’s 3%, from our perspective, maintenance updates, as long as they have a limited scope in the code, should be subject to lower standards vs the standards required for ArbOS updates, governor changes, etc. But for this, the Constitution should be changed so that we include this subcategory with a new quorum threshold.
Now, if we are going to use the current 4.5%, there is something to consider: Generally, the DAO reaches this threshold in the last days of voting, within a 14-day process. This tells us that it is likely that we will have difficulty reaching the quorum in just a week, even when there is unanimity about the veto.
We mention all this because if the system forces a vote by default and we finally decide to have a 14-day vote with the constitutional quorum instead of changing the Constitution, we will have a process quite similar to the existing one except for the initial engagement with the Council and the Template, and the fact that if delegates don’t vote, there’s no quorum and therefore no veto, but the vote and delay exist anyway. Having said this, we have some final questions:
-
As we asked before, it would be interesting to know the technical nature of the proposed changes, whether we are dealing with a new governance module that should be included as a proposer in the L2Timelock, or if we are making changes directly to the existing Governor.
-
Will the Security Council have any role in this process? We understand that it wouldn’t be optimal for the Security Council to have the Maintenance Council role since it’s necessary to involve OCL, and it would imply having a Maintenance Council that rotates every 6 months, but it would be interesting for them to maintain veto power over transactions sent to the L2Timelock.
-
Wouldn’t a model where you only vote when necessary be better? With the current proposed model, delays exist by default due to the DAO’s veto window. Considering what was explained above regarding the quorum and the days needed to reach it, at the end of the day, all projects would still need to wait 14 days of voting to list their tokens unless we change the Constitution, and there wouldn’t be much difference with the current governance process.