---
robots: noindex, nofollow
---

# Agenda Items

* RESILIENCY ISSUES. Problems that we think we can address in the Ethereum Ecosystem.
* BLOCKCHAIN COMMONS TECHNOLOGIES. A quick overview of our resilience technologies.
* PROPOSED PROJECTS. Projects using our technology that we think can address resiliency issues.
* WHAT ARE WE MISSING. Are there Ethereum issues you'd like to see solved that might be in our wheelhouse as a creator and developer of interop specifications?
* HOW CAN WE MOVE FORWARD. What's the next step?

# Ethereum Talking Points

## Problems

* Single Keys Have Been Baked into the Ethereum Ecosystem from the Start

Because of early decisions made in wallet development, most Ethereum accounts depend on a single key for control and usage, particularly Externally Owned Accounts (EOAs). This creates a single point of failure.

* Single Keys Are Widely Used

Worst, those single keys are used for a wide variety of purposes. A single key might control ETH, NFTs, and smart contracts. There's no meaningful separation of different keys for different proof purposes. This means that that single point of failure is multiplied across all Ethereum assets & usages: if a user loses a single key, it's all gone.

* Contract Accounts and Account Abstraction (AA) Have Not Solved the Problem

AA may offer some real solutions for the Ethereum ecosystem if it were widely deployed, but per its specification in ERC-4337 it doesn't solve the issues of key management. Though a key might be generated via a different means than a seed using AA, a signing key is still required to control the contract wallet. Unless use of multikey authentication becomes widespread, AA may even worsen problems by grouping all control into that contract wallet, solidifying the key centralization that is already a long-term trend in the Ethereum ecosystem.

With that said, it's not obvious AA is going to be widely deployed. It seems to have hit its high point almost exactly a year ago before going into decline. Recent reports say that AA UserOperations are just 1-2% of transactions. One of the newest attempts to improve the adoption of AA, EIP-7702, does so by giving contract superpowers to traditional EOAs, doubling down on classic problems.

Whether 4337 or 7702 ultimately do make better inroads into the ecosystem, we need to be able to better protect user assets NOW.

* There's No Standardized Way to Protect Users' Assets

The fundamental problem of a single key being used to protect many assets and other operations is multiplied by the fact that there is no standardized way in the Ethereum ecosystem to protect that key, and therefore a user's assets. Even when some solutions exist, such as the possibility to use a passkey for AA control, they introduce new issues (such as the centralization of key control under a big corporation like Google or Apple because of their control of cloud storage).

* There Has Been Insufficient Analysis of Privacy Implications in the Ethereum Ecosystem

On a separate topic: Ethereum has done lots of innovative things with its smart contracts, including the newer AA functionality. But it hasn't done a lot of analysis of privacy threats that might emerge, such as correlation, censorship, or other coercion. This puts a big question mark on a lot of Ethereum usage.
privacy

## What We Have

We have technologies that can help:

* OIB. Object Identity Block. Help users to ID their assets and keys.
* LifeHash. Visual hash to improve identification of assets.
* SSKR. Sharded Secret Key Reconstruction. Split up a key for later reconstruction in case of loss.
* Envelope. Stores seeds or keys in packets. Optionally, shard the keys to the packets with SSKR.
* CSR. Collaborative Seed Recovery. Use SSKR & Envelopes in an automated way online.

## What We Can Do

* Survey Ecosystem

We think it's import to start with a survey of the ecosystem, focusing on extant wallets (though we know that MetaMask was 60% of the wallet ecosystem at last analysis). We want to especially look at how wallets are using seeds and keys and how they're storing and maybe even backing up that key material. This will provide us with the foundation that we can improve upon (and will also allow us to report out for future use by others).

- Output: Report on Wallet Survey

* Write SmartCustody for Ethereum

We've previously written a Bitcoin-focused book on protecting digital assets for users. We now want to write an Ethereum-focused white paper or short book on protecting digital assets for developers. The goal would be to help developers to immediately upgrade to best practices and technologies that would improve the resilience of keys and seeds if they want to, and otherwise to lay the ground work for more direct work with those developers.

Topics in the book/paper would include the following

Best Practices:
- How to secure EOAs
- How securely transfer them
- Solving Ambient Authority Issues
- Improving User Experiences
- Object Identity Blocks (OIBs)
- Partitioning by Proof Purpose
- Warm, Cool, Cold Wallet Differences
- Multiaccount wallets

Resilience Technologies:
- SSKR to Shard Seeds
- Envelopes to Store Seeds
- GSTP/CSR as a Next Step

- Output: Smart Custody for Ethereum book or paper

* Hold Developer Meetings

The next step is to directly support & encourage wallet developers to use these best practices and technologies. To offer further support, we'll run meetings for developers with demos and presentations, to be recorded for further usage.

If any developer shows particular interest, we'd want to give them personal support.

- Output: Recorded demos & presentations & Q&A

* Connect with MetaMask

Since MetaMask likely still holds the majority of the Ethereum wallet market, we'd ultimately want to work with them to make sure that our resilience improvements get to the largest audience possible. Anything that could be done to help us with that goal would be extremely useful.

- Output: Resilience Improvements for Metamask

* Write Privacy Risks Report

Finally, on the orthogonal issue of privacy, we'd want to do a full analysis on various issues, and report that out, with recommendations to improve privacy.

===

For our Thursday call, here are some specific questions I'd love to explore from my side:

**Organizational Structure Questions:**

- Should we consider rebranding away from "Blockchain Commons" given the terminology issues you identified?
- Is European formation worth exploring for better funding access? (Dutch foundation, Swiss association, Estonian e-residency?)
- How do we position against Protocol Labs model (they had $250M ICO advantage we lack)?

**EF-Specific Opportunities:**

- Could Strategic Architecture Partnerships help EF avoid the surveillance infrastructure risks in wallets?
- Is there a path for BC to be EF's architectural coherence layer for the "beyond seed phrases" initiative? (nicolas?)
- Would EF fund development of coercion-resistant wallet standards based on TAoA principles? (really next focus privacy)

**European Strategy:**

- Who in your network should see The Architecture of Autonomy? (PSE team? Other grant recipients?)
- Would framing as "European digital sovereignty infrastructure" resonate with EU funders?
- Could we structure as a European FRO / FRC (https://www.renaissancephilanthropy.org/uk-horizons-frc) with US operations rather than vice versa?

**Partnership Model Refinement:**

- Is $10K/month still the right price point for 2025?
- Should we offer different tiers (architectural review only vs. full partnership)?
- How do we demonstrate ROI when the value is "preventing inadvertent oppression"?