Cp0x Delegate Communication Thread

Voting Rationale & Governance Calls Delegate Statements
,
242

Extending DRIP’s Mandate

DRIP is an incentive program for attracting liquidity directly from users.

Out of 80 million ARB, only 63.7 million ARB remain; they’ve only actually completed one of the four planned seasons. They were supposedly revising the program to accommodate a new strategy. The downside is that they’ve been significantly delayed, and the ARB value is currently at a minimum.

It could be extended, since there are no salaries, and the ARB is still there; no one is asking for new ones.
(I voted FOR this DRIP last year.)

Vote: FOR
Platform: Snapshot

243

OAT Elections

The OAT’s job is to hold the OpCo accountable, so we put most of our weight behind independent candidates with the fewest conflicts of interest.

Manoj Desai got the largest share — he’s the cleanest on conflicts, and his work is focused on delegate participation and accountability, which is exactly what this committee deals with. Alex Netto came next: a strong governance-security record (Blockful, the ENS Security Council) and consistent work against over-centralization. We spread the rest across Varit Ruangsiri and Zeptimus (steady, transparency-focused work), Pedro Breuer (the least-conflicted sitting member, for continuity), and a smaller share to Jojo, who knows the DAO well.

We didn’t support Patrick McCorry or A.J. Warner — one is tied to the Foundation, the other is CSO of Offchain Labs. An accountability committee shouldn’t include the parties it’s meant to oversee.

Vote: Weighted
Manoj Desai 25% / Alex Netto 20% / Varit Ruangsiri 15% / Zeptimus 15% / Pedro Breuer 15% / Jojo 10%
Platform: Snapshot

244

Fast Feed

Fast Feed is a paid, authenticated data stream that gives subscribers an earlier view of the sequencer’s already-ordered transactions. 97% of the revenue goes to the DAO Treasury and 3% to the Arbitrum Developer Guild.

We voted FOR. It’s a new revenue stream for the DAO at no cost to the treasury — Offchain Labs covers the development and the Trail of Bits audit. The revenue split and the RewardDistributor contract are the same ones already approved and running under Timeboost, so this isn’t new ground.

The key point for us: the feed only publishes data after ordering has been set by the sequencer. Subscribers get an earlier look, but they can’t frontrun, sandwich, or change ordering — it’s an information product, not an ordering privilege. Pricing is permissionless and EIP-4844-style, so buying up all the tickets becomes exponentially expensive and monopolization isn’t rational.

One concern worth noting: Offchain Labs holds the MARKET_PARAMS_SETTER role for two years, which is some operational centralization. But the DAO keeps DEFAULT_ADMIN and BENEFICIARY_SETTER and can override or revoke at any time. We’ll review the Trail of Bits audit and confirm the deployed contract matches the spec before the on-chain vote.

Vote: FOR
Platform: Snapshot

245

[Constitutional] Ratification of Security Council Election Process Improvements

Temp check on four fixes to the SC election process: 2-year cohorts instead of 1, candidate threshold down to 0.1% from 0.2%, and key rotation for both candidates and members.
Longer cohorts and a lower threshold cut down on election fatigue; the threshold drop is just a correction as supply grows. Key rotation has sensible safeguards (Foundation veto + 3-day buffer for candidates, SC veto + 18-day timelock for members). Trail of Bits audit with fix review is done.

Vote: FOR
Platform: Snapshot

246

Constitutional AIP: ArbOS 61 Elara Upgrade

Fixed version of ArbOS 60 (two gas-refund bugs touched the STF, so it needed a new version; same scope, One/Nova were never on 60). For One and Nova it does two things: raises the Stylus contract size limit from 24 KB to 96 KB (Stylus only, no Solidity/EVM impact, clear win for Rust teams), and adds a BaseFeeManager letting Offchain Labs move the min L2 base fee within 0.01–0.10 gwei without a full vote each time.

The base-fee delegation is the part worth watching, but the guardrails are fine: tight range, expires in 2 years, every change announced on the forum, DAO can revoke anytime, audited by Trail of Bits. Good that Dynamic Pricing is not activated and the special OCL pricing rights were dropped. AltDA API, compliance filtering and priority fees ship disabled on One/Nova. No cost to the DAO.

Vote: FOR
Platform: Onchain (snapshot.box)

247

[Constitutional] AIP: Security Council Election Process Improvements

On-chain vote now, after the temp check (#245). Same four fixes: 2-year cohorts instead of 1, candidate threshold down to 0.1% from 0.2%, and key rotation for candidates and members.

Longer cohorts and a lower threshold cut down on election fatigue; the threshold drop is just a correction as supply grows. Key rotation has sensible safeguards (Foundation veto + 3-day buffer for candidates, SC veto + 18-day timelock for members). Trail of Bits audit with fix review is done. The on-chain payload moves no funds, it’s a single ArbSys execution on the standard constitutional path.

Vote: FOR
Platform: Onchain (snapshot.box)

248

[Constitutional] PGA + Fast Feed

The case for replacing Timeboost is pretty clear. Three entities took around 97% of auction wins, while most atomic arbitrage and nearly all liquidations bypassed it. Moving to PGA makes sense.

We read the implementation, not just the summary. Giving the Toggler chain-owner status is a broad permission, but the contract itself is narrow: the manager can only switch tip collection on or off, and after two years anyone can remove the Toggler as chain owner. One detail is worth clarifying: the expiry is not self-enforcing, so setCollectTips() still works after year two until someone calls the permissionless revoke().

Our remaining questions are around Fast Feed.

The 18 August update limits Offchain’s control over Fast Feed payment parameters to two years, but that limit does not appear in the on-chain text: the two-year references there apply to the Toggler and K. We would rather see the Fast Feed limit enforced by the payment contract itself.

There is also a concrete gap around deployment. On 22 July, Offchain confirmed that the existing Timeboost RewardDistributor cannot be reused for Fast Feed, since each RewardDistributor handles a single asset and Fast Feed payments are in an ERC-20 stablecoin. The proposal acknowledges this and says the dedicated deployment will replace that address in the final on-chain proposal materials. These are the final materials, and the old address is still there; the payment asset and role assignments aren’t specified either.

The execution section says the final payload and proposal description must enumerate the calls, targets, addresses, role assignments and parameter values, and must separate what the payload executes from authority granted for later. For Fast Feed, neither side is fully specified.

The July update also promised periodic accounting, public dashboards and a separate distribution vote every six months. We expect those commitments to carry through once PGA is live.

None of this changes our vote. The PGA side is well specified and the Toggler is narrow and audited. The unresolved pieces sit mostly in Fast Feed infrastructure that has not been deployed yet. We’ll check the final contracts, addresses, roles and revenue routing when it goes live.

Vote: FOR
Platform: Onchain (Snapshot.box)

249

Arbitrum Security Program

We support continued audit coverage for builders and recognize AAP’s first-year results; our vote is about the budget structure, not the program’s purpose. The bug bounty and Security Council have been carried by the Foundation to date and are also covered within the aggregated technical lines of the Foundation’s 2027 funding approved in June. ASP creates a second permitted funding source for these same functions without explaining how the two budgets will be reconciled, whether the corresponding Foundation spending will be reduced, or whether ASP funding is meant to supplement it.

At the same time, audits and AI screening are the only pillar without a defined amount in the proposal’s budget; the 18 August deck marks it “from remaining balance.” With the Council’s $720k/year fixed and bounty payouts mandatory when triggered, the program’s original builder-audit purpose becomes the residual category. A minimum floor for the audit pillar and a spending priority between pillars were requested by several delegates and not provided, as were a definition of “low-risk” for idle funds and bounds on the 14-day optimistic process. Our questions remained unanswered through the close; we will assess the first quarterly reports against these points and revisit at renewal.

Vote: AGAINST
Platform: Offchain (Snapshot)

250

Adopting USDG as a Core Strategic Initiative for the ArbitrumDAO

We understand the concern behind this proposal, since most of the DAO’s costs are in dollars while its revenue comes in ETH and other volatile tokens. That mismatch can be addressed by converting revenue as it arrives, and the ATMC already holds around $66M in money market funds and stablecoins. It does not by itself justify committing an additional 100M ARB to USDG growth, alongside AEP fee conversions and treasury allocations to a single issuer’s stablecoin. We are also not convinced the GDN line is as uncorrelated as described. Supply growth would be driven by ARB-denominated incentives whose dollar value falls when ARB declines, and rewards are paid from the yield on USDG reserves, which moves with interest rates.

The key economics are not disclosed. Delegates are asked to vote without knowing the terms of Arbitrum’s GDN agreement, which entity receives the rewards, or what revenue to expect, while the text notes that the OAT and the AAEs are read in on parameters that cannot be published. Most rewards would be reinvested during a growth phase with no defined end, and the proposal does not specify what share of rewards will reach the treasury management portfolio during that phase or when that share will increase.

KPIs are to be set by the OAT after the vote, and we think that order should be reversed. When we studied spending at Lido, Aave, Sky and Uniswap in 2023–2025, only 14 of 58 major spending and incentive decisions stated a goal in terms of public metrics, and growth incentives showed mixed results a year later (cp0x study). The DRIP Season 1 data shared in the proposal thread also shows uneven retention, with four of the six lending protocols below their pre-campaign borrowing levels 180 days later. The proposal more than doubles the program’s remaining budget without publishing retention targets or tying the taper to results.

The mandate is broad and hard to unwind. The list of ATMC actions, including bilateral deals with protocols, is explicitly open-ended, DRIP expands to POL, liquidity arrangements and deals with integrating teams whose terms are difficult to assess from outside, and the remaining separate seasons are merged into a single USDG-focused season. Conversion covers already accrued AEP fees as well, without quantitative slippage limits or OTC execution requirements disclosed in the proposal. If the program is ended, only uncommitted funds return to the treasury, spent incentives cannot be recovered, and existing positions may need to be unwound.

The plan also concentrates a growing share of treasury value in one issuer’s stablecoin, chosen through a review of issuers that has not been published and without a USDG-specific exposure cap disclosed in the proposal. Finally, four separate decisions are bundled into a single vote, so delegates who support part of the plan have no way to say so.

Vote: AGAINST
Platform: Snapshot

251

Transfer 1,700 ETH from the Treasury to the Arbitrum Developer Guild & ATMC’s ETH Treasury Strategies

We support paying the Arbitrum Developer Guild its share of Timeboost and PGA revenue. Based on the stated figures, 3% of the combined 2,750.42 ETH in Timeboost revenue and 87 ETH in PGA revenue is approximately 85.1 ETH, and the payment follows the allocation set out in the Timeboost and PGA AIPs. Our vote is against the allocation of 1,614.9 ETH to the TM portfolio, which in its current form does not give delegates enough clarity to support it.

A central argument for the allocation is that additional ETH would help restart the covered call strategy. The March proposal put the portfolio’s ETH weight at 39.7% and projected around 47% after the 6,000 ETH transfer, at an assumed price of $2,200. This proposal puts the weight at about 37% with an assumed price of $2,700. These percentages alone do not establish whether the portfolio’s ETH holdings have declined. The proposal does not reconcile the current allocation with the position projected in March or explain the contributions of portfolio flows, rebalancing and valuation changes. It also explains the current reluctance to restart covered calls, but does not provide a dated account of when and why the strategy was paused or whether previous options resulted in ETH being called away.

The March proposal included sector yields against benchmarks and linked to a detailed allocation breakdown, while this one gives a cumulative figure of almost 600 ETH and a roughly 2–7% range for the 30-day moving-average annualized yield. Questions about this in the proposal thread were answered with a reference to arbdata.com and the IPS. The portfolio overview does not clearly identify whether the covered call strategy is currently active and notes that certain assets temporarily held offchain are excluded. The proposal does not say where the covered calls are executed or how the new tranche would be split between covered calls and other strategies.

Bundling the guild payment with the portfolio allocation also means that delegates cannot express separate preferences on the guild payment and the portfolio allocation through this vote. We would support a version that votes on the two separately, reconciles the portfolio’s ETH position with the March projection, and sets out how the new tranche would be deployed.

Vote: AGAINST
Platform: Snapshot

252

[Constitutional] AIP: Update Arbitrum One and Nova L1-Pricing Parameters for Ethereum Glamsterdam

Glamsterdam raises the cost of posting batches to Ethereum, and with the current values the L1 pricer on One and Nova could underestimate batch-posting costs after the fork. The proposal raises perBatchGasCharge from 210,000 to 480,000 and parentGasFloorPerToken from 10 to 16, with the latter matching EIP-7976. This is a parameter change through ArbOwner with no Nitro software or ArbOS version upgrade, and no additional DAO funding is requested. The update adjusts the L1 fee calculation to reflect higher post-fork posting costs.

We decoded the payload data in PR #384. It schedules a fork gate on Ethereum and the same parameter action on One and Nova, with no transfers or role changes. The action contract is deployed on both chains with constants matching the proposed values, the live parameters are still 210,000 and 10, and the gate currently reverts because SLOTNUM is not yet available on mainnet. We will check the onchain proposal against this payload once it is submitted. The open question for us is the gas refunder, since the post-fork estimate assumes the batch poster runs without one.

Vote: FOR
Platform: Snapshot

253

[Constitutional] AIP: Establish an L1 Voting Recovery System

We support the direction of this proposal. The ordinary DAO governance process depends on the L2 governor, with the Security Council providing an alternative route for repairs. An independent route on L1, with voting power still tied to delegated ARB, gives tokenholders a way to repair governance if neither of those is available, and we think that is worth building.

There are a few things we think are important to address as the proposal moves towards its final form.

The proposal said the affected chains would be confirmed before the temperature check, and the section still reads “to be confirmed”. It would help to know whether Arbitrum One, Nova or both are in scope.

The motivation describes the L1 path as a last resort, while the constitutional text makes it available at any time in addition to the ordinary process. We would like the text to reflect the stated purpose more closely. One option worth discussing is a Security Council cancellation role on the new L1 timelock. On the existing L1 timelock, CANCELLER_ROLE is held by the L1 Upgrade Executor, on which the 9-of-12 Security Council holds EXECUTOR_ROLE, so the Council can already cancel queued operations there. A similar arrangement could prevent misuse of the L1 path while the Council remains functional, but it would also let a compromised Council block recovery.

At the same time, a compromised Council that is still able to act has authority through the L1 Upgrade Executor and, depending on the final ownership configuration, may also be able to affect the new contracts through their proxy admin. The proposal should explain how it balances these failure scenarios and state clearly which of them the L1 path is and is not designed to cover. It could also be worth limiting the L1 path in the Constitution to actions needed to restore ordinary governance, such as repairing governance contracts, Security Council membership and rollup recovery.

The rule against duplicate or conflicting AIPs needs an exception for proposals stalled by the governance failure the L1 path is intended to address. Under the current definition of pending, such an AIP may neither fail to pass nor be implemented, which would make submitting the same recovery action on L1 inconsistent with the constitutional rule indefinitely. We would suggest that an AIP stops counting as pending if it has not been implemented within a set period after its earliest executable time, with a separate rule for AIPs that get stuck before they can be queued. The design should also specify how any queued operations from superseded AIPs would be cancelled or otherwise prevented from executing after recovery.

We also share the point raised by Arb_Junior and TodayInDeFi about stale state. Since there is no maximum assertion age, delegates need clear guidance on how to assess voting power taken from an old confirmed assertion during a long outage.

Finally, we look forward to the specification (l1-voting.md is referenced but not linked), a permissions map showing what the new timelock can reach through both upgrade executors, test results and the audit. It would also help to know who will maintain checkpoint monitoring over time, and whether delegates are expected to cover L1 gas for proofs and voting during an emergency.

Thank you to Offchain Labs for working on a scenario most of us hope never happens.

Vote: FOR
Platform: Snapshot