As of today blockchain accounts are isolated in their capabilities and responsibilities. They can't easily delegate authority to an external account to perform operations on it's behalf. It's an all or nothing situation.

But why is that a problem, you might asking?

Because without the ability to delegate authority and control, we severely limit the full potential of an integrated Web3 user experience.

Accounts, and their accompanying permissions ultimately become fragmented.

The user experience becomes cluttered with points of friction. And basically all operational security best practices are ignored because every account is the "sudo" account i.e. if it's compromised everything is lost.

Dennison is working hard

@DennisonBertram

Every time I see a story like this:

"there but for the grace of god, go I".

Increasingly I want to have two wallets:

One that holds my shit, and one that interacts with shit. The problem is, the airdrops always go to the one with the shit.

I'm still thinking about how to…

Bill Lou

@BillLou95

I'm devastated guys...

I just got scammed out of $125k of stEth while trying to claim the $LFG airdrop. And I'm a fking founder of a wallet startup that's trying to improve wallet security...

I can't believe this is happening, I've always been so careful. I saw article guide to…

8

4:28 PM • Jan 2, 2024

Is this an unavoidable feature of blockchain accounts?

Something we just have to live with forever in the EVM? Maybe... But, hopefully not.

Improved Account Management

As I started out saying, Ethereum accounts don’t have native permission delegation capabilities. In other words you can’t tell the EVM “Hey! I want this third-party account to be able to act on my behalf and with limited permissions.” It simply doesn’t exist.

But that’s O.K. because the EVM is turing complete. We can build these abstractions. And as luck would have it, we might even be able to take inspiration from an idea that's been around for 50+ years.

Object capabilities.

The object-capability model is a computer security model. A capability describes a transferable right to perform one (or more) operations on a given object… The object-capability model was first proposed by Jack Dennis and Earl C. Van Horn in 1966.

And this object capabilities model has already been thought about in the context of smart contracts by Dean Tribble.

Computer scientist E. Dean Tribble stated that in smart contracts, identity-based access control did not support well dynamically changing permissions, compared to the object-capability model. He analogized the ocap model with giving a valet the key to one's car, without handing over the right to car ownership.[4]

The structural properties of object capability systems favor modularity in code design and ensure reliable encapsulation in code implementation.

These structural properties facilitate the analysis of some security properties of an object-capability program or operating system. Some of these – in particular, information flow properties – can be analyzed at the level of object references and connectivity, independent of any knowledge or analysis of the code that determines the behavior of the objects. As a consequence, these security properties can be established and maintained in the presence of new objects that contain unknown and possibly malicious code.

Object-capability model - Wikipedia

http://wikipedia.org

The Wikipedia entry is a bit dense, so I asked ChatGPT to create a summary.

The "Object Capabilities" security paradigm for digital permissions is a model used in computer systems to control access and maintain security. Here's a summary of its key aspects:

1. Principle of Least Authority (POLA): In this model, each component or user in a system is granted the minimal set of permissions necessary to perform its tasks. This principle limits the potential damage that can be done if a component is compromised.

2. Objects as Secure References: In the object-capability model, an "object" refers to any component that can perform actions or store data. Each object has associated capabilities, which are essentially permissions or references that allow it to perform specific actions or access other objects.

3. Capabilities as Access Tokens: A capability is a communicable, unforgeable token of authority. It represents the right to perform a specific action on a specific object. For example, having a capability for a file object might allow reading from or writing to that file.

4. No Global Authorities: Unlike other security models that rely on a central authority to enforce access control, the object-capability model decentralizes this control. Each object governs its own capabilities.

5. Direct Authorization: Access is granted through direct possession of a capability. If an object does not possess the required capability, it cannot access the resource. This avoids the complexity and vulnerabilities associated with managing access control lists or other indirect authorization methods.

6. Transferring Capabilities: Capabilities can be passed from one object to another, allowing for flexible but controlled delegation of authority. This transfer must be explicit and controlled to prevent unauthorized access.

7. Granularity of Permissions: The model allows for fine-grained control over permissions. Capabilities can be crafted to be very specific, limiting access to precisely what is needed.

8. Immutability and Revocation: Capabilities are generally immutable; once created, their permissions cannot be altered. However, systems often implement mechanisms to revoke capabilities, effectively removing access rights.

9. Transparency and Encapsulation: Objects in this model can interact without needing to know the internal workings of other objects, as long as they possess the necessary capabilities. This encapsulation is key for maintaining system integrity and security.

10. Compatibility with Distributed Systems: The object-capability model is particularly well-suited for distributed systems, where objects may reside on different servers or in different domains, since it avoids the need for a central authority.

Overall, the object-capability model provides a robust and flexible framework for managing digital permissions, emphasizing direct authorization, decentralization, and minimal privilege to enhance security.

Enough of the technical details - blahhh - let’s get too the fun stuff!

The only project I know of that’s working on this approach is Delegatable an object capabilities like framework for the EVM, which gives blockchain based accounts the ability delegate capabilities/authority to a new account.

Delegatable is unlike any other delegation solutions we have today. The framework is not prescriptive in what capabilities should be delegatable - only that permissions and capabilities should be delegatable.

But don’t we already have today!?

Yes and no - with an emphasis on no.

For example there is many such cases where you can “delegate” ERC20 voting power without transferring the balance. Hold OP tokens? You can delegate them. What about ARB tokens. Yup, you can delegate those too.

But all of that happens at the token level. Not at the account level.

This is what makes delegatable so special. The account is responsible for delegating onchain permissions/capabilities without requiring support from an external contract.

And it’s quite clever in how it achieves this.

Enforcer Modules

At the core of Delegatable is what are known as enforcer modules. These enforcers modules are evaluated at run-time and constrain how a transaction can be executed.

To delegate permissions you sign an offchain EIP712 message, that references these enforcer modules. And within that signed message is embedded rules and conditions.

Once this message is signed, you send the delegation (object capability) to whomever is receiving the permissions. When that “leaf” account is ready to execute a transaction on behalf of the “root” account it will take that signed permission, craft a transaction and broadcast the bundle via the root smart account i.e. smart contract.

Practical Use Cases

Delegatable first started as a *wild* idea to build an onchain credit network.

Conceptualized by Dan Finlay in a 2019 post - almost 5+ years ago.

https://medium.com/capabul/minimum-viable-consensus-algorithms-with-object-capabilities-6059f926ab88

Let’s say Alice and Bob want to transact rapidly, each depositing $100, but not run a state channel validator. They want the cheapest possible validator they can get. They perform a search of their mutual social graph for someone who runs a validating computer, and propose Claire. Alice trusts Claire up to $1000, and Bob doesn’t trust Claire at all.

The two parties then sign a new ocap that delegates permission to sign updates to Claire, who does not need to post any collateral for Alice (who trusts Claire), but fully collateralizes Bob’s channel, with a challenge period, so if Alice or Claire tries to close the channel in an early state, they can withdraw, and Bob could still have a challenge period during which he’s fully insured.

At the time I thought it was a very interesting (even radical) idea. Today, less so. Not, because it’s any less interesting or radical, but simply because it’s way ahead of its time. And not practical for today’s environment. Perhaps in the future though.

So where does idea fit within today’s landscape?

Account Security Best Practices

When reading about object capabilities, the literature always seems to frame delegating permissions to a third-party. Some nebulous account/user that you’re giving permission to act on your behalf. Or maybe that’s just me - I’m not the best reader.

But either way, I think that’s the wrong way to think about object capabilities for blockchain. Or at the very-least the wrong to think about them in the currently market cycle.

You won’t primarily be sharing permissions with third-party accounts.

You’ll be delegating permissions amongst accounts you own.

Specifically separating permissions based on different account security practices.

And this will especially be the case, once embedded wallets and browser based wallets via PassKeys become more mainstream. In short, without account native delegation, fragmentation is inevitable - but that doesn’t have to be the case.

Root & Leaf Accounts

Chances are you have a primary blockchain account.

It holds a majority of your assets and is probably even a hardware wallet. You try not to connect this wallet to suspicious applications and you take all the necessary precautions to keep it safe - physically and digitally.

But it’s cumbersome. Signing a transaction, small or large, is a hassle. It requires physically locating the hardware wallet, which in reality is not always possible.

This hardware wallet is essentially your “root” account. It holds the most assets, capabilities and value - it should be protected at all costs.

But sometimes you want to perform tasks without all of the included friction.

Sharing Account Permissions

A smart account with delegatable enabled, can authorize external (leaf) accounts to act on behalf of the primary (root) account with very specific permissions.

Permissions for what you might be asking? Everything! And anything.

• Transferring X amount of tokens between Y-Z time ranges.

• Updating onchain records like the Ethereum Name System.

• Exiting a risky position during a black swan event.

• Moving liquidity into profitable trading ranges.

And these external smart contracts don’t need to support “delegation” because everything happens at the account level. The transactions are actually coming directly from the “root” account.

Delegation for Decentralized Finance

Let’s imagine you’re a liquidity provider for a USDC/ETH Uniswap liquidity pool.

But, as you know, you only earn fees when trading occurs in your liquidity range.

In this hypothetical world ETH has on average traded between $2,000 and $2,050. So that’s the range you provide liquidity - anything out of that range and you’re essentially losing money.

And since you provide a substantial amount of liquidity ($100,000+) you don’t want to manage the position using a hot wallet, because you’re smart, and know a hardware wallet is the best way to secure your assets.

While here in lies the problem.

You don’t always have access to that hardware wallet, and the prices starts to become volatile. So when the price moves out of your liquidity range, you are no longer earning fees, because you can’t easily change your liquidity range.

Dang. That’s a problem.

But what if you could authorize a hot wallet, or even a third-party service, to automatically update your liquidity range, without losing custody?

That would be nice, right?

While, that’s possible with Delegatable. You can authorize an external account to switch liquidity ranges on your root accounts behalf - and only switch liquidity ranges.

The authorized account can’t transfer funds, exit a liquidity position without re-entering one or do anything else you haven’t given explicit permissions to do. All thanks to the power of an “object capabilities” like framework.

Conclusion

Blockchains account don't have native authority delegation capabilities. Because of this, it makes it difficult to properly secure a high-value account - it's an all or nothing situation.

Object capabilities provide a framework for applying security best practices in a distributed digital environment. The https://github.com/delegatable framework, inspired by ocaps, applies these practices and asks the question "How we can introduce better security practices into the blockchain account primitive?"

If we are going to scale blockchains to millions, let alone billions of users, account native authority delegation has to be a core feature in future smart account standards.

The unique approach to account permissions, will introduce better wallet security best practices, and perhaps even create an environment for an improved user experience for everyday blockchain actions.