Who, when, what — a framework for thinking about plugins, and 7579 vs 6900

In our last blog post, we argued in favor of ERC-7579 over ERC-6900 as a standard for modular smart accounts. The blog generated a lot of healthy debate, including a detailed response from Noam at Alchemy.

But you might wonder, why do 7579 and 6900 differ at all? That is, why would two groups of rational and intelligent people disagree so strongly on a technical issue? Shouldn’t everyone be arriving at the same, correct conclusion?

In this post, we will show that 7579 and 6900 differ due to a fundamental difference in philosophy. That is, there’s no strict right and wrong—it’s a matter of your perspective. Yes, just like most things in life.

To begin, let’s examine the most fundamental question: what does a smart account plugin even do?

Who, When, What

Every use case of smart account plugins must answer three questions: who, when, and what.

• Who is authorized to perform this action? (The Validator)
• When (i.e. under what condition) can they perform this action? (The Hook or Policy)
• What exactly is this action? (The Executor)

Here are some examples of viewing use cases through this lens:

• NFT Subscription: The DApp (who) can mint an NFT for me (what) once every month (when).
• Limit Orders: The DApp (who) can send a trade for me (what) when the price reaches a given point (when).
• Social Recovery: A set of guardians (who) can change the account signer for me (what) at any time (when).

While the line is not cleanly defined—a validator could answer both who and when—we believe that a well-designed plugin will answer only one of these three questions, to keep the scope small and clean.

Who Puts the Pieces Together?

This leads us to ask: if a plugin only answers one of these three questions, who is responsible for putting three plugins together to solve a use case?

Therein lies the key difference between 7579’s and 6900’s design philosophy:

StandardPhilosophyResponsibility for Plugin AssemblyERC-6900The plugin developer decides how plugins fit together.Dependencies are specified in the plugin's "manifest" at build time.ERC-7579The plugin user decides how plugins fit together.Dependencies are defined by the user/DApp at install time/run time.

When you develop a plugin in 6900, you specify a “manifest” that lists the dependencies between plugins. For example, a social recovery executor (what) must specify that it must be validated through the guardians plugin (who).

In 7579, no such dependencies need to be specified when plugins are developed. The developer creates the executor (what), another developer creates the validator (who), and it’s only when the user installs the plugins that the association is made. (Note: The "plugin user" here is usually the DApp that assembles the plugins for the end user.)

That’s why you might hear the statement that “ERC-6900 is ERC-7579 plus permissions,” which is not far from the truth. ERC-6900 is opinionated about how permissions are tied together, whereas ERC-7579 leaves permissions out of scope.

Which Approach Is Reasonable?

It depends on what you prioritize.

• When each plugin specifies its own dependencies (6900), you achieve higher portability because the DApp doesn’t need to decide how plugins fit together. However, plugins become less composable.
• With Kernel (and ERC-7579), we opt for composable plugins, because we believe that:
  • It makes plugin developers' lives easier since they can develop smaller, simpler plugins.
  • It gives more power to users & DApps because they can mix-and-match plugins to solve use cases that the original plugin developers may not have thought of.

For example, consider Kernel’s signers (who) and policies (when) plugins. You can match whichever signer with whichever policy, enabling an exponential number of use cases:

• Use an ECDSA signer with a gas policy.
• Use a WebAuthn signer with an execution policy.
• Use a WebAuthn signer with a gas policy + contract policy.

By not hardcoding any dependencies between plugins, we allow DApp & wallet developers to compose plugins at will. Using the ZeroDev SDK, the code looks concise:

TypeScript

const account = await toKernelAccount({
signer: webauthnSigner,
policies: [contractPolicy, gasPolicy]
})

In other words, with Kernel & ERC-7579, you get to compose plugins at “run time” (when plugins are used), as opposed to at “compile time” (when plugins were built).

Last Words

It’s important to note that both ERC-6900 and ERC-7579 are actively evolving. That said, we do believe that the difference in philosophy—where the responsibility for composition lies—will likely persist and drive the design decisions of each standard.

In a way, this very debate proves the point that the “proper” way to design smart accounts is far from settled. That’s why we push for smaller standards like ERC-7579 over bigger standards such as ERC-6900: to preserve room for projects to experiment and innovate, which ultimately will result in better smart accounts for the next billion Web3 users.