Today I’m happy to start publicly sharing some early but working Ethereum tools that enable general purpose delegation in Ethereum. This is the culmination of years of thinking about what is missing from the computing blockchain ecosystem, and I’m eager to see what the community does with it.

A few things it helps address:

• Onboarding without needing gas
• Minimizing the need to onboard to a “wallet”
• Help users make smaller, more deliberate connections to applications.
• Maximize the interconnectivity of smart contracts
• Allow smart contract developers to write less security sensitive code
• Enable transaction batching
• Create social systems that are maximally responsive & dynamic.
• Enable applications to benefit from trust that may exist in their communities.
• Enable deploying devices with the minimum set of permissions without needing to transfer funds or perform transactions.
• Allow transactions to not be blocked by each other (nonce queue issues).
• Provide tools to reduce key reuse across devices.
• Provide a framework for dynamic, accountable, and highly liquid allocation of scarce resources.

Background & Theory

You don’t need to know any of this background to recognize the value and start using it today, so feel free to skip this section if you want to get to the practical bits.

In 2016 I first started becoming very certain that there was some kind of design that could allow highly dynamic and responsive social organizations. I recognized that Moloch DAO was addressing the same general issue but with a very different approach, which introduced latency. I had enough problems in mind that required highly responsive organizations that I wanted to find the best possible solution to social scalability that does not depend on time locks.

This problem was feeling very challenging in part because defining “trust” can seem damn near impossible. For simplicity’s sake, I took a detour and tried reducing the problem to lending: Representing what is risked as “just” money.

I spent a year reading any proposal I could for decentralized credit systems, but mostly found myself tearing them apart. My review of Dfinity’s Phi was pretty entertaining, I think.

I eventually articulated a concept well enough that my twitter community was able to direct me to some prior art, and that led me to two concepts that would end up guiding a lot of my work for the next couple of years: social collateral and object capabilities.

Social collateral in short is the idea that you can trust someone with anything as long as they value your relationship more than that thing. Your social relationship is a form of collateral. People don’t want to get cut out. There’s some great economics literature about how scalable and secure this tool can be, how it actually underpins the banking system already, and how it de-facto underpins most casual lending relationships.

My research on social collateral led me to seek patterns that could allow people to issue transitive allowances to each other (I grant you an allowance, and you can grant it to someone else), and that led to me meeting folks who have been working on systems like that such as Trustlines, Circles UBI, as well as approaches that focus on scalability like XLN (Extended Lightning Network).

I wrote a rough description of a specification in this gist on github, and was quickly directed to the zcap-ld specification at w3c by Mark Miller and Christine Lemmer-Webber, Agoric, and the extensive prior literature on what they call object capability security. What their work showed me was that the secure scalability properties of social collateral were not exclusive to the economic and financial, but could be considered a general framework for managing access around any sensitive resource.

This made a lot of sense, because a recurring challenge of defining a system of trust is trying to define trust, and reducing it to the form of a financial allowance was always obviously reductive. In the object-capability framework, you aren’t always granting a financial allowance delimited in dollars, you can provide access to any function, delimited with whatever computable caveats you can dream of. Here I felt like I had found home, where we were uniting the maximally secure with the maximally expressible.

In 2019 I wrote a public appeal for someone in the Ethereum ecosystem to take up this cause and implement it, but nobody did. I’ve been pretty busy making MetaMask, so I kept feeling pulled away from this, but during a break in early 2022, I finally took the steps to sit down and begin it.

The Delegatable framework does not achieve what I would call pure object capabilities, because it still involves developers needing to manage signature and delegation code, although I’ve started a library that hopefully makes it somewhat ergonomic. The object in object capabilities comes from object oriented programming, and is meant to mean that the syntax of the programming language itself represents the distributed delegation system as mere reference passing. Therefore, I might call this a capability security framework for Ethereum, but have chosen the name Delegatable Eth for the sake of trying to more simply convey the core benefit to the most possible readers.

The Agoric Blockchain is one where the syntax of the smart contract language itself does achieve object-capability security by using a secure subset of JavaScript, but on the Agoric blockchain every delegation (by default) is an on-chain action. A novel benefit of the Delegatable Eth framework is that all delegations can be performed off-chain, and for some applications this can enable highly off-chain side-networks of “counterfactual” transactions that could be submitted. I think it remains to be seen how significant a scaling benefit this offers, but I think the MobyMask proof of concept has a pretty promising example of getting a large amount of functionality out of a very small number of on-chain transactions. A similar framework could be built on top of Agoric’s blockchain, but it would lose the ergonomics of keeping the capability management within the language’s syntax.

The design of Delegatable Eth is extremely similar to and obviously inspired by zcap-ld, but with the unique feature of being validated by any Ethereum Virtual Machine, bringing its benefits to any Solidity contract that inherits from it, instead of simply bringing these benefits to a centralized server. By running a private blockchain as a validator, a consumer of Delegatable Eth could use it in a similar way to zcap-ld if they wanted to.

Developer Experience

By inheriting from this solidity class, any contract gets a host of features:

• Support for MetaTransactions
• Support for batched operations: Many actions in one transaction, and potentially lower gas costs.
• Support for signing multiple actions that aren't blocked by each other, so an urgent transaction isn't blocked by the low nonce of a low-stakes low-gas bid transaction.
• Support for signing commitments that can be lazily submitted to the blockchain later.
• Allow users to sign off chain messages that delegate authority to perform any action they can perform
• Every delegation includes support for an open-ended system for adding restrictions to that delegation, including revocation.
• Allow the holder of any delegation to issue a delegation from it (transitive invitations), also with an off-chain signature and no transaction fee.
• Allows creating invite links to users who don't have accounts set up yet, by signing delegations to a key you send along with them.

Integrating the Delegatable library is as simple as inheriting from a solidity class, and overriding `_msgSender()` (and using that method instead of `msg.sender` directly).

Once inherited, the resulting contract allows any user to sign delegation methods that allow them to share anything they can do on that contract with anyone else. You can see some sample delegation signatures in these tests. These delegation messages are off chain, and include any number of “caveats”, which can include special restrictions like revocability, allowances, call limits, time limits, or eventually with some changes, even multi-sigs and additional forms of cryptography.

Some example caveats that a delegation message include:

• Revocation
• Allowed methods
• Limited call count
• Time limit
• Token Allowance
• NFT allowance
• Parameter ranges
• Approved recipients

You can look at how it works by looking at the implementation of the invoke method here. It can also help to read the type file that is used to generate much of the signature validation code. You can see what it looks like to sign delegations in JS with this library eth-delegatable-utils.

To help guide initial development, I chose to start with the anti-phishing registry use case as MobyMask because it a very simple contract, is a pressing and dire issue, has relatively low stakes if it turns out to be flawed, and it demonstrates a non-financial use case for a blockchain, which I think could be a useful cultural bridge for expanding the discourse of what blockchains are good for. I believe it’s valuable to think about how applications that minimize reliance on a blockchain can still leverage one for key security critical operations, like managing a sensitive access policy.

I think distributing negative reputation in the form of a phishing list is ultimately an incomplete solution, and is only needed on sites where public replies by default and paid ads are the norm, and this issue could be more completely eliminated by changing those norms, but via this tool I hope to demonstrate how these web3 tools can help solve web2 problems.

Long term, there are a wide range of possible uses for making a smart contract Delegatable, but I think it could benefit just about any smart contract. Some ideas:

• Finer grained allowances, without needing on-chain transactions.
• Site logins that imbue any number of on-chain permissions
• Issuing transitive allowances, enabling a form of micro-credit.
• Providing a kind of peer to peer insurance without reliance on a global oracle.
• Creating a referral economy that incentivizes honest reviews and rewards influencers.
• Off chain restricted order books can allow any number of deal-finders to get a commission, while also reducing the possible buyers, which could help combat miner extractible value.

Part of why I’m a fan of EIP-3074 or EIP-5003: AUTH_USURP is that they would allow any ETH account to benefit from all of the features I’m showing off in the delegatable framework for free, for all contracts they interact with, with no transactions needed until an on-chain action is performed.

If you’d like to try contributing to MobyMask, you can find it on github here.

If you’d like to try out the Delegatable framework, you can find it on github here.

If you want to hear me talk more on this topic and how it relates to my broader work at MetaMask, I discuss it a bit on the Epicenter podcast here.

If you’d like to join me and help build a more dynamic, secure, and cheap decentralized future, we’re hiring.

Thanks for reading ❤️