Note: starting 30 mins later, so not overlapping with Glamsterdam Sepolia activation & watch party
Meeting Time: Tuesday, October 06, 2026 at 14:30 UTC (60 minutes)
The meeting focused on the progress and planning of the Frames DevNet, with participants discussing the successful deployment of Frames DevNet Zero and the current state of the network. The group decided to add EIPs 7906, 8272, and 8250 to the next devnet, with some concerns raised about the design of EIP 8250 but ultimately moving forward with its inclusion. Updates were shared on client implementations, with Nethermind having already implemented 7906 and working on Matcha. The conversation also covered the strategy for merging Frames and Fossil devnets, aiming for a combined Hegata devnet in the future. Other topics included proposed changes to the verification gas limit for mempool transactions and the handling of max fee cost bounding, with further review needed before decisions. The conversation ended with reminders about open PRs and ongoing discussions around simulating Frame Transactions via JSON RPC.
The team discussed the status of Frames DevNet Zero, with Barnabas reporting that it appears to be functioning correctly at 100%. Barnabas also mentioned that they have a spammer instance running on the network that is sending French transactions at a rate of approximately 10 pairs per block.
The team discussed the current status of Frames DevNet Zero, which has approximately 10 transactions per block using FrameType transactions. Barnabas suggested continuing with the current scope until more client readiness is established, rather than waiting for additional client implementations. The group agreed to move forward with adding EIPs 8250 and 8272 to DevNet 1, with potential consideration of EIP 7906, based on recommendations from EtherX, Nethermind, and Matt.
The team discussed adding EIP 8250 for keyed nonces to DevNet 1, with lightclient expressing concerns about the precompile approach from a protocol design perspective, citing potential migration issues when changing the tree structure in the future. Soispoke explained that while the current implementation may seem hacky, it’s necessary for supporting multiple transactions per sender and the solution would need to be migrated to a dedicated PVT branch later. The discussion highlighted that while there are no better alternatives currently available, the team acknowledges this is not the ideal long-term solution and would need to be revisited when moving to PVT.
The team discussed EIPs and user-facing changes, with lightclient expressing concerns about a proposed approach involving system contracts, though acknowledging it as the best available option. The group agreed to move forward with EIPs 8250, 8272, and 7906 for the next dev net, with Nethermind confirming 7906 is already implemented. Marc proposed a one-week timeline for implementation, which received support from multiple participants including Barnabas who advocated for faster deployment rather than a slower, more gradual approach.
The team agreed to add three new EIPs (7906, 8272, and 8250) to Frames DevNet 1, with a target launch date of Thursday of the following week. Guru confirmed that EIPs 8250 and 8272 were already in progress, while EIP 7906 would be prioritized for completion by mid-next week. Barnabas suggested maintaining a two-week cadence for future DevNets, with the next one (FramesDevNet 2) scheduled for three weeks out, and the potential for a merged DevNet with Fossil three weeks after that.
The team discussed proposed changes for DevNet 1, with lightclient presenting updates to the expiry verifier implementation and seeking approval for deployment. The group agreed to proceed with deploying the expiry verifier using Nick’s method, but decided to postpone the max fee cost bounding changes until DevNet 2 to allow more time for review. Daniil raised a question about potentially changing the verification prefix limit for mempool to test complex scenarios involving keynotes and recent routes, though the discussion was cut off in the transcript.
The team discussed implementing Matcha and agreed to set a transaction limit of at least 300K, with Daniil suggesting 500K as sufficient. Soispoke explained that higher limits are important for testing private transactions and wallet workflows on the testnet. Marc also mentioned a discussion about relaxing the halting parameter for frame transactions in the EF Magicians thread, though no immediate decisions were made on this topic.
The team discussed the transition from Fossil and Frames DevNets to the new Hayabusa DevNet. Barnabas confirmed that they would stop using Fossil and Frames DevNets once Hayabusa DevNet 0 is available, with everything moving to Hayabusa instead. The group agreed that merging the DevNets earlier would be beneficial for Hayabusa’s potential to be one of the fastest post-merge forks, aiming for completion in under 7 months. Barnabas suggested starting offline discussions about scoping DevNet 2 and potentially making a decision by Thursday if they want to complete the Hayabusa merge by the end of the month.
The team discussed adding items to Thursday’s agenda, with Barnabas agreeing to add a decision-making item. They reviewed a PR change suggested by Matt regarding frame specs, which Anders confirmed he had reviewed and approved. The meeting covered DevNet 1 scope targeting next Thursday, which includes the addition of three new EIPs (8272, 8250, and 7906), and they planned to continue discussions about when DevNets should merge at Thursday’s meeting.
Daniil proposed redefining MaxVerify gas as a shared mempool floor rather than a hard limit to allow for more flexible transaction verification across nodes. He explained that this approach would create an organic gradient where nodes could handle transactions with varying verification prefixes, with some being slower but guaranteed to meet a minimum verification floor. Lightclient expressed concerns about sending transactions to peers who cannot verify them, arguing it could worsen mempool optimization issues rather than improve it.
The team discussed implementing a protocol to communicate verification limits between nodes, with lightclient expressing concern about adding unnecessary complexity to the network. Marc reminded the team about 13 open PRs against frames that need attention before the next DevNet meeting. The group also briefly touched on a discussion about simulating Frame Transactions via JSON RPC method, which was raised by Jack, though no decisions were made and the team agreed to revisit it in the next call.
+4RuV!Zg)+4RuV!Zg)+4RuV!Zg)YouTube recording available: https://youtu.be/r7w0rd_TCxo