🫱🏻‍🫲🏼 Safe access control to improve security and UX

Safe Development Infrastructure
1

Using your Safe as an account should be secure AND easy-to-use

Safe’s launch of the January 2023 Take Back Back Ownership movement is a perfect time to prioritize both technical and UX opportunities that have a large impact on Safe adoption and usability for both financial and account ownership. The past few months I’ve been exploring sign in with Ethereum (SIWE) platforms like Farcaster and Lens Protocol/Lenster.

The current state of crypto wallets as accounts is inconvenient and/or not secure.

  • Tokens like NFTs and approved wallet addresses are used for gated communities, products, and services.
  • You need to use a wallet that you have daily access to in order to regularly use these apps, making this process insecure.
  • Or you can go through the inconvenience of accessing a cold storage wallet every time for access to these apps.

For users that sign in with a secure cold wallet and/or a Safe the UX with most SIWE and token-gated apps is not sustainable because these more secure wallets are more complex to access by design. Without a change in UX these platforms that are pioneering self-ownership of identity, messaging, and data will fail to gain adoption leaving us with the same centralized options.

Delegation

A Tweet by DCinvestor at the end of 2022 introduced me to the strategy of delegating access from secure accounts to accessible accounts.

  • This works by a secure wallet delegating custom and flexible access to apps to an easy-to-use and accessible wallet.
  • E.g. Allow a hot wallet to claim airdrops that are deposited into cold storage.

In SafeDAO we have the option to do this currently with SAFE tokens and governance. A SAFE token holder can delegate their tokens to another address to vote directly on Safe Ecosystem Proposals (SEPs) powered by Snapshot.

  • SAFE holder signs an on-chain transaction that writes to Snapshot’s publicly accessible registry of approvals granting voting power denominated in SAFE tokens to a specific delegate.
  • That delegate votes on a SEP and Snapshot reads from the registry in order to determine the amount of voting power based on the delegate’s tokens held and and the tokens delegated to them.

Delegate Cash

This led me to the Delegate Cash team who is focusing on solving this through a variety of open and immutable strategies including EIP-5649. They take a similar approach to Snapshot. However, with a public registry that anyone can write and read from for their wallets, accounts, and apps. Delegate Cash currently secures $240mm. foobar explains Delegate Cash clearly and succinctly in this post.

Solution for Safes

Potential features

These features could live within a Safe module in the desktop, web, and mobile apps similar to the Spending Limit module. Strategically, it’d be best to focus on an initial killer use case first, like delegating token gating, or whatever the community decides is most impactful.

  • Manage delegations: Set permissions, view, and revoke
  • Build custom permissions
  • View all active and past permissions
  • Revoke
    • E.g. All or specific owners can revoke access.
    • Time parameters
  • More convenient self-access to other apps
    • E.g. Social and gaming
  • Compartmentalize access
    • E.g. Different levels of access for social and gaming vs finance vs treasury apps
  • Social recovery governance permission
    • Specific permissions to apps, features, and limits
  • Issue shares by delegating NFTs or tokens
    • Instead of sharing multiple signing keys
  • Improve Spending Limit module
    • Extend spending limits to non-owner wallets
  • Potential to build off of or improve Snapshot delegation of $SAFE governance tokens

Note: It’s important to be mindful of module naming as a potential token allowance management module, e.g. Revoke.cash, and delegation module would need to be clearly communicated.

Collaboration

The Delegate Cash team is open to working together with both the core Safe team and ecosystem of developers on top of Safe to build solutions and help publicly support adoption of these new features.

  • Customization/white labeling
    • Can abstract the Delegate.cash technology completely from the UX or partner with Delegate.cash to showcase it.
  • Delegate.cash (Including foobar) have bandwidth to support co-marketing efforts

The Castle wallet built on Safe has integrated Delegate Cash for the BAYC and MAYC tokens and is a great example of Safe’s use case with delegation.

Tech

Delegation features

  • Wallet addresses
  • Contracts like Uniswap and LensProtocol
  • Tokens like ERC-20, NFTs like ERC-721, and etc.

Networks – Ethereum, Polygon, and Goerli (Compatible on all EVM protocols)

Implementation options

  1. Smart contract
  2. Javascript SDK/API
  3. Integrate with a trusted provider who has integrated, e.g. A bridging service.

Alternatives

Cookies

As an alternative to delegation registries apps could allow users to save their sign in app token (not crypto token) via web and mobile cookies. Similar to how you can sign into Twitter on Firefox and stay logged in for days. This helps with convenience, but still is a security issue given the secure wallet may need to be accessed from time to time.

Other delegation tools

  • Solutions
  • Items to research
    • How do these compare from a high-level in terms of implementation?
    • Do they require trust in a third party for the off-chain transactions?
      • I do not see a mention of on-chain transactions or making use of existing or new EIPs, e.g. EIP-5649.
3 Likes
2

Hey! Wanted to share some updates from Castle. We added delegate cash abilities a few weeks ago and we are almost at 10 delegates (lol). We had half our users use the safe app and the other half use our beta app (beta.castle.link)

Though the delegate cash feature is awesome, I think it’s still a bit early for people to use / understand / etc. at scale. I’m starting to see more NFT projects include delegate cash as an option (for airdrops, tickets, etc.) so I think in a year or so we’ll start seeing more people understand this and then use the feature.

In terms of how this could work on the base layer of safe, I think having it upfront in the safe UI, better education, and maybe even a module / handler of some kind added to the base contracts that can make it a bit more native to the safe experience. I think we’ll see have to see the market adopt delegate cash at a slightly larger scale before we can think about changes to the core safe contracts.

2 Likes
3

Thank you for sharing these details @mehran!

Pain points
Are there specific parts of the delegation process users or potential users had trouble with? Understanding this could help those who implement delegation in their app in the future.

Safe base layer
I agree with having a Safe module.

  • Clearly defined use cases for most users. If there are a few killer apps that emerge it would make sense to build these first, e.g., Sign-in with Ethereum/X token, to a popular social app
  • Customization similar to Transaction Builder for advanced users.
4

I’ve updated the research in this open guide, Crypto account access control.

New additions

  • Sismo is interesting as it potentially provides more privacy because it uses zk-proofs to create Soulbound tokens using a contract to assign specific access.
  • Delegatable created by Dan Finlay, the co-founder of MetaMask takes the approach of integrating access controls directly into an app’s contract instead of a contract needing to be updated to integrate with an outside registry like with Delegate.cash.

Useful research to be done would be to learn more on the decentralization of each solution as well as estimating the return-on-investment.

1 Like
5

Awesome stuff Adam!

I have been putting some thought into this stuff lately too and coming to some similar places. I think Sismo is awesome just by the nature of which it is essentially privacy-preserving delegation. However, by no means is the exhaustive use case of Sismo.

I believe the best framing umbrella term for this is “Access Control” defined as the permissioning to perform an operation. In the context I have seen delegation, it is usually a single operation/function access control, eg delegate permission to vote.

I think other areas for thought are between Role Based Access Control (RBAC) and Attribute Based Access Control (ABAC).

RBAC being permissions to perform actions based on a role. Eg using the Spending Limit Module the Treasurer of a DAO Treasury can have permission to transfer limitted amount of funds, essentially authorized users to perform an action.

ABAC being permissions to perform actions based on an attribute. Eg a permissioned access control could be that NounsDAO NFT holders are allowed to vote, a user with the attribute of being an ownerOf a NounsDAO NFT.

There is a team that’s quite close to the Safe developer team as far as I can tell from the repo being in the gnosis safe github org working on this kinda thing you can check out here :slight_smile:

Keen to keep tabs on this thread and thanks for sharing your research :zap:

1 Like
6

I believe the best framing umbrella term for this is “Access Control”

Yup. I went through a few naming iterations based on delegation, permissions, and ultimately arrived at Access control as a generic that can be applied to many specific use cases as you mentioned, role based access control (RBAC) and attribute based access control (ABAC).

Thank you for highlighting Zodiac! I’ve heard about Zodiac from a high-level and need to research the specific features of their APIs/contracts. I added Zodiac to the open guide and look forward to learning more.