The following reflects the views of the Lampros DAO governance team, composed of Chain_L (@Blueweb) and @Euphoria, based on our combined research, analysis, and ideation.
We are voting FOR this proposal in the Snapshot voting.
Firstly, thank you to the @offchainlabs team for putting this together and engaging in the thread. We read the post end-to-end and compared the changes against what builders on One and Nova depend on today.
We agree with the direction. Staying close to Ethereum reduces maintenance risk, and enabling BLS12-381 and CLZ brings real wins for developers. Keeping the pricing work to measurement only is also a prudent choice at this stage.
Since the per-transaction cap equals the block limit, we kindly ask for a short note with recent chain data to back this choice: P95 and P99 gas used per transaction over the last 90 days, any instances where a single transaction filled most of a block, and a brief check that large single transactions do not impact sequencing fairness. If these numbers show headroom, the 32M setting is easy to support; if they suggest pressure, we can discuss a safer margin now rather than later.
Measuring first is the right approach. To help everyone review before any later activation, it would be helpful to expose a minimal telemetry surface for the new counters (compute, storage access, storage growth, history growth), either via JSON-RPC or a Prometheus endpoint, and to share a short outline of the activation playbook when you return: which parameters can change, how changes would roll out, what checks define “go / no-go,” and how a revert would work if needed. This keeps the next step predictable for node operators and the DAO.
We support including it in the codebase while keeping One and Nova unchanged. For completeness, please confirm there is no configuration path that could enable Mint/Burn on One or Nova in this release, and share the audit artifacts for the Dia diff when ready. For Orbit chains that opt in, a short operator checklist and the clean migration path if a bridge provider changes would be useful. A concise “assumptions matrix” that maps token/bridge choices to added trust would also help teams make informed decisions.
These fixes are welcome. A brief regression summary noting the test coverage and any expected effect on batch posting costs or node resource usage would make planning easier for infra teams. If there is no material impact, stating that clearly is helpful.
We understand activation could land after Fusaka due to constitutional timings. That is fine if the audit report, the RC metrics snapshot, and the upgrade notes are public before Tally.