• Safe{Core} Protocol.

• EF ESP Q2 allocation update.

• The free data availability problem.

Apply here: ether.fm/nft

nft://10/0xC375FB001C0414369cA1b84757f68002ba47D062/?showBuying=true&showMeta=true

Listen on: Apple | Castbox | Spotify | YouTube | Lens

Smart contract wallet provider Safe introduced the Safe{Core} Protocol, an open-source modular framework designed to enhance the transition from EOAs to smart contract wallets. The protocol aims to establish a vendor-agnostic core standard that encourages component reuse, maintains strong security, and promotes interoperability and diversity among smart accounts. Safe aims to address fragmentation, vendor lock-in, and security concerns through standardized modules and registries. The protocol's design includes a Manager abstraction layer for handling the roles of Registries, Accounts, and Modules. Safe released a whitepaper outlining the new protocol specifications.

The EF Ecosystem Support Program released an allocation update of projects that received funding in Q2. A total of $9.2 million was allocated to 58 different projects. Categories include community & education, consensus layer, execution layer, cryptography and ZKPs, developer experience and tooling, and protocol growth and support. Grant recipients include Nethermind, Nimbus, mevboost.pics, and Beaconcha.in. The EF Ecosystem Support Program (ESP) runs several initiatives focused on providing both financial and non-financial support to teams. Users building projects that enhance the Ethereum ecosystem can visit esp.ethereum.foundation to view funding options.

Ethereum researcher Mike Neuder proposed a design to tackle the free data availability issue in inclusion lists. Inclusion lists ensure specific transactions are included in blocks. The design divides the inclusion list into a "Summary," signed by the proposer, and an unsigned transaction list. The process involves construction, inclusion, and validation phases. In construction, the proposer creates a signed Summary and an unsigned Txns list, sharing it with the network. Inclusion involves the next proposer using the observed Summary, and validation checks the block using the state-transition function, requiring each Summary Entry to be satisfied for validity. This approach enables commitment to transactions without exposing their details, therefore averting data availability vulnerabilities.

• Safe{Core} Protocol.

• EF ESP Q2 allocation update.

• The free data availability problem.

Apply here: ether.fm/nft

nft://10/0xC375FB001C0414369cA1b84757f68002ba47D062/?showBuying=true&showMeta=true

Listen on: Apple | Castbox | Spotify | YouTube | Lens

Smart contract wallet provider Safe introduced the Safe{Core} Protocol, an open-source modular framework designed to enhance the transition from EOAs to smart contract wallets. The protocol aims to establish a vendor-agnostic core standard that encourages component reuse, maintains strong security, and promotes interoperability and diversity among smart accounts. Safe aims to address fragmentation, vendor lock-in, and security concerns through standardized modules and registries. The protocol's design includes a Manager abstraction layer for handling the roles of Registries, Accounts, and Modules. Safe released a whitepaper outlining the new protocol specifications.

The EF Ecosystem Support Program released an allocation update of projects that received funding in Q2. A total of $9.2 million was allocated to 58 different projects. Categories include community & education, consensus layer, execution layer, cryptography and ZKPs, developer experience and tooling, and protocol growth and support. Grant recipients include Nethermind, Nimbus, mevboost.pics, and Beaconcha.in. The EF Ecosystem Support Program (ESP) runs several initiatives focused on providing both financial and non-financial support to teams. Users building projects that enhance the Ethereum ecosystem can visit esp.ethereum.foundation to view funding options.

Ethereum researcher Mike Neuder proposed a design to tackle the free data availability issue in inclusion lists. Inclusion lists ensure specific transactions are included in blocks. The design divides the inclusion list into a "Summary," signed by the proposer, and an unsigned transaction list. The process involves construction, inclusion, and validation phases. In construction, the proposer creates a signed Summary and an unsigned Txns list, sharing it with the network. Inclusion involves the next proposer using the observed Summary, and validation checks the block using the state-transition function, requiring each Summary Entry to be satisfied for validity. This approach enables commitment to transactions without exposing their details, therefore averting data availability vulnerabilities.