Social Safe accounts 💚

Social Safes

The Safe Pass launch is a wonderful opportunity to expand Safe as the digital account for self ownership of social, messaging, data, collaboration, and identity, in addition to assets.

Safe actions rewarded

Transaction count: The number of transactions made with your Safe Account


Weekly user: You will be rewarded for using your Safe Account on a weekly basis

Will Safe{Pass} include non-financial actions that are secured by users’ Safe as their sign-on method or that they hold their account NFT with?

Examples of social protocols and apps potentially aligned with Safe

  • Ethereum Name Service (ENS) held by Safe account (Extra points per each setting and feature enabled)
  • Unique versions of a file saved to Fileverse
  • Messages sent on XMTP and PushChat
  • Meaningful interactions with POAP, Farcaster/Warpcast, Yup, and Lens

Assets stored: The USD value of the assets that are stored on your Safe Account

It’s nice to see Safe is also rewarding users for Safe’s original use of securing assets.

Locking SAFE privacy

Locking SAFE is a good first use case. The process of locking SAFE requires users with multiple Safes to move SAFE tokens into one account. Directly transferring SAFE into a public-friendly account reveals all of the users Safe accounts.

Coinbase has listed SAFE so that is an option for Coinbase users to send their SAFE through to their public-friendly Safe account. This exchange strategy does not provide full privacy, but is an improvement from directly transferring SAFE from all of your existing Safe accounts.

4 Likes

Set an ENS avatar with Safe account

ENS is a great place to start exploring Social Safes because ENS provides fundamentals to owning your digital identity, messaging, access controls, publishing, etc.

After moving ahurwitz.eth into my social Safe to secure my ENS in a smart account, I played with customizing ahurwitz.eth by setting an avatar.

Has anyone set an avatar for their ENS name that is held by their Safe account?

I’m able to successfully approve the offchain Safe approvals to set an ENS avatar. However, I’m not able to get to the onchain confirmation of the ENS action.

I’ve attempted both through the ENS Safe app and in the ENS app connecting to Safe through WalletConnet.

Expected

When I update my ENS avatar with an externally owned account (EOA), the “Confirm Details” view shows successfully after approving the offchain action(s), allowing me to finalize the avatar update onchain. This view does not show when attempting to update the avatar with Safe.

Observed

ENS Safe app (app.safe.global)

  • Approve ENS avatar “Sign and upload” directly in the ENS Safe app
  • Error: After approving the required amount of Safe actions nothing happens in the ENS app

ENS app with WalletConnect (app.ens.domains)

  • Approve ENS avatar “Sign and upload” by connecting to the ENS app through WalletConnect
  • Error: After approving the required amount of Safe actions the ENS app shows the error “Invalid signature” or “An unknown RPC error occurred. Details: Request expired. Please try again. Version: viem@2.9.15”.

Errors

  • With both methods there is a message when approving the transaction, “This message does not conform to the EIP-712 specification”. I’m not sure if this is related.

  • After the required threshold of approvals are completed on Safe, the onchain confirmation view is not showing. Instead of the “Confirm Details” view that shows when using an externally owned account (EOA), it shows the errors shown in the “Observed” section or nothing.

Workaround

Serenae.eth, who’s part of the ENS DAO, provided me the steps to set my avatar manually.

  1. Open the ENS app through the Safe app (app.safe.global) or directly (app.ens.domains) > Go to your ENS profile > “Records” tab
  2. Add a value with a “key” of avatar, the “value” to a public URL of my avatar, and complete the required number of approvals for your Safe.
  3. View the avatar image set on the “Profile” tab.

Attempted solutions

  • Clearing browser cache and cookies
  • Turning ad blockers and the VPN off
  • Changing the order that each approval account signs the Safe approvals
  • Browsers attempted: Firefox 126 and Chrome Version 124.0.6367.93
  • Shared with
    • ENS Discord
    • Safe support chat

Next steps

Much appreciated!

1 Like

Are Safe accounts built to work with Gitcoin Passport and the Devcon raffle apps?

Ethereum’s Devcon conference coming up in Bangkok, Thailand is one of the largest opportunities to showcase the power of using social Safe accounts for security, convenience, and customability.

For $0.009 I created a Safe on Arbitrum for the Ethereum Devcon raffle today. I used a Safe so that I can have custom multifactor authentication (MFA) for my account. That is auth across multiple devices, apps, people, locations, etc. as secure or convenient as I’m comfortable with for this specific Devcon account.

  • To use raffle.devcon.org Safe needs to work with Gitcoin Passport. Unfortunately when I attempt to verify any stamp such as LinkedIn or Safe I receive the “Verification Failed” error.
  • It’s important to know the Devcon site also was unable to check the Safe accounts Passport score even though the Safe was able to successfully sign messages

Hopefully I can work with the Safe, Gitcoin, and/or Devcon teams to have Safe accounts working with the Devcon raffle deadline by this Tuesday.

Attempted solutions

  • I’ve tested on both Firefox and Brave browsers
  • Disconnected VPN and ad blockers
  • Cleared cache and cookies
  • Posted in the Gitcoin Discord “:speech_balloon: | peer-help” channel and messaged the Gitcoin Intercom support with the console logs

Details

Gitcoin Passport “Verification Failed” error

Gitcoin Passport Console log 401 error

5027-b60e02c5fa6a938f.js:1 verify - submitted, canSubmit false true false
5027-b60e02c5fa6a938f.js:1 geri banner {heading: ‘Verifying Contribution Activity’, content: ‘For the Contribution Activity credentials, make su
 contribution history with your Gitcoin Passport!’, cta: {
}}
_app-e57793770c737a07.js:1

  POST https://rum.browser-intake-us3-datadoghq.com/api/v2/rum?ddsource=browser&ddtags=sdk_version%3A4.19.1%2Cenv%3Aprod%2Cservice%3Apassport-prod&dd-api-key=pub55edecb6ea7e86a241c204e990cb47c2&dd-evp-origin-version=4.19.1&dd-evp-origin=browser&dd-request-id=2230230d-1046-41e0-8234-22484b31968a&batch_time=1720409905937 net::ERR_BLOCKED_BY_CLIENT

sendBeaconStrategy @ _app-e57793770c737a07.js:1
sendOnExit @ _app-e57793770c737a07.js:1
Batch.flush @ _app-e57793770c737a07.js:1
Batch.flushOnExit @ _app-e57793770c737a07.js:1
(anonymous) @ _app-e57793770c737a07.js:1
callMonitored @ _app-e57793770c737a07.js:1
(anonymous) @ _app-e57793770c737a07.js:1
_app-e57793770c737a07.js:1

  POST https://logs.browser-intake-us3-datadoghq.com/api/v2/logs?ddsource=browser&ddtags=sdk_version%3A4.19.1%2Cenv%3Aprod%2Cservice%3Apassport-prod&dd-api-key=pub55edecb6ea7e86a241c204e990cb47c2&dd-evp-origin-version=4.19.1&dd-evp-origin=browser&dd-request-id=e61a686d-0364-47e4-acdf-a7ecf7500271 net::ERR_BLOCKED_BY_CLIENT

sendBeaconStrategy @ _app-e57793770c737a07.js:1
sendOnExit @ _app-e57793770c737a07.js:1
Batch.flush @ _app-e57793770c737a07.js:1
Batch.flushOnExit @ _app-e57793770c737a07.js:1
(anonymous) @ _app-e57793770c737a07.js:1
callMonitored @ _app-e57793770c737a07.js:1
(anonymous) @ _app-e57793770c737a07.js:1
_app-e57793770c737a07.js:1

  POST https://passport-iam.gitcoin.co/api/v0.0.0/verify 401 (Unauthorized)

(anonymous) @ _app-e57793770c737a07.js:1
instrumentationWrapper @ _app-e57793770c737a07.js:1
(anonymous) @ _app-e57793770c737a07.js:109
em.exports @ _app-e57793770c737a07.js:109
em.exports @ _app-e57793770c737a07.js:109
Axios.request @ _app-e57793770c737a07.js:109
Axios. @ _app-e57793770c737a07.js:109
(anonymous) @ _app-e57793770c737a07.js:109
fetchVerifiableCredential @ _app-e57793770c737a07.js:1
await in fetchVerifiableCredential (async)
handleFetchCredential @ 5027-b60e02c5fa6a938f.js:1
await in handleFetchCredential (async)
Nb @ framework-d7f437c5cbc76ba6.js:25
Tb @ framework-d7f437c5cbc76ba6.js:25
Ub @ framework-d7f437c5cbc76ba6.js:25
nf @ framework-d7f437c5cbc76ba6.js:25
se @ framework-d7f437c5cbc76ba6.js:25
(anonymous) @ framework-d7f437c5cbc76ba6.js:25
Rk @ framework-d7f437c5cbc76ba6.js:25
Jb @ framework-d7f437c5cbc76ba6.js:25
hd @ framework-d7f437c5cbc76ba6.js:25
fd @ framework-d7f437c5cbc76ba6.js:25
ed @ framework-d7f437c5cbc76ba6.js:25
_app-e57793770c737a07.js:1 Error: Request failed with status code 401
at em.exports (_app-e57793770c737a07.js:109:45276)
at em.exports (_app-e57793770c737a07.js:109:48601)
at XMLHttpRequest.onloadend (_app-e57793770c737a07.js:109:39048)
console. @ _app-e57793770c737a07.js:1
handleFetchCredential @ 5027-b60e02c5fa6a938f.js:1
await in handleFetchCredential (async)
Nb @ framework-d7f437c5cbc76ba6.js:25
Tb @ framework-d7f437c5cbc76ba6.js:25
Ub @ framework-d7f437c5cbc76ba6.js:25
nf @ framework-d7f437c5cbc76ba6.js:25
se @ framework-d7f437c5cbc76ba6.js:25
(anonymous) @ framework-d7f437c5cbc76ba6.js:25
Rk @ framework-d7f437c5cbc76ba6.js:25
Jb @ framework-d7f437c5cbc76ba6.js:25
hd @ framework-d7f437c5cbc76ba6.js:25
fd @ framework-d7f437c5cbc76ba6.js:25
ed @ framework-d7f437c5cbc76ba6.js:25
5027-b60e02c5fa6a938f.js:1 verify - submitted, canSubmit true true false
5027-b60e02c5fa6a938f.js:1 geri banner {heading: ‘Verifying Contribution Activity’, content: ‘For the Contribution Activity credentials, make su
 contribution history with your Gitcoin Passport!’, cta: {
}}

Devcon raffle Passport check signed confirmations

Much appreciated!

Update opportunity for Gitcoin Passports for Safes

Skylar, one of the Devcon leads followed up quickly on X and helped us research the problem further.

  • Gitcoin Passport doesn’t support smart accounts as they haven’t built a way to verify stamps across mutliple networks, e.g. Ethereum mainnet and Arbitrum.
  • This is a similar situation to many use cases with multinetwork Safes that teams are solving for with push/pull data management strategies, proofs, bridges, etc.

The Gitcoin Passport team will need to work with Safe builders moving forward to support multinetwork Safes.

2 strategies for Safes to work with Gitcoin Passport

A. User “connects” 2 Safes on different networks by verifying each on Gitcoin Passport on each network 1 time. All future stamp verifications are shared using a push or pull model.
B. User verifies the same stamp across Safe accounts on different networks for every stamp.

1 Like

Opportunity to own your work and data

Own your work and data. Build freely with people. :yellow_square::green_circle::globe_with_meridians:

Fileverse uses distributed data storage and Safe accounts to provide infinite future customization and features. I’m impressed from creating a Fileverse dDoc open info (OI) view how smooth and performant dDocs is 1 month into the proof-of-concept launch.

Don’t trust, verify: http://ddocs.new

I’m looking forward to manage dDocs with my current Safe account, ahurwitz.eth in the future.

  • Multifactor authentication (MFA)
  • Management for teams, organizations, etc.

Currently Fileverse uses ERC-4337 to create Safe accounts for each user automatically.

1 Like

Full and shared approval accounts

The original use of social Safes is social recovery. There are many useful potential customizations of social recovery like time delays, levels of approval power, approval specified for specific assets and tokens, etc.

A simple form of social recovery that would be great to include natively in Safe and benefit many users is a binary “full” and “shared” approval accounts.

This is useful because it allows Safes to increase resiliency through recovery options without giving approval accounts too much unintended power.

  • Enabled directly in the native Safe app, app.safe.global, when you add a new approval account.
  • New option below “Threshold” for “Approver account type”

Full approval

This is the current approval account that can create and approve onchain for all Safe actions

Shared approval

After more than 1 shared approval account is added only 1 of n shared accounts can approve an action at any given time.

E.g. There are 4 approval account for a Safe, A, B, C, and D with a 2-of-4 approval threshold

  • A and B are an individual owner’s accounts on different devices/locations
  • C and D are shared approval accounts of coworkers/family/friends
  • Access to account A is lost and the owner asks account C to add a new approval account to replace A.
  • C creates an action to add a new account.
  • Because C and D are shared approver accounts D cannot approve or create new action until the current action is approved or denied.

Future shared approval account groups

  • Future features of shared approval accounts could include another option when adding an approval account for a shared approval account group.
  • In the Safe example above perhaps account C and D are added to the shared group “coworkers”, and then accounts E and F are later added under the group “family”.
  • In effect only 1 shared account from each group “coworkers” and “family” can approve or create a Safe action at any given time.
1 Like

@Kurt_Larsen from Rhinestone shared the demo @koshik and the Zen Guard team built this past year for Safe session keys using ERC-7579 and the Safe7579 adapter. This can be used to build a simple version of “full” and “shared” approval accounts.

Kakusan from Brahma’s Console shared their account access controls feature. I need to research further to see if there is a simple premade policy similar to the “shared” approval account concept. That is where only “x of n” from a group of n can initiate/confirm Safe approval account recoveries (Account additions and removals).

1 Like

Just dropping some more resources here:

Smart Sessions Manager (Session Keys) we are working with Bico to get this module framework into audit next week. So docs will be coming shortly.

ERC-7715 is the standard the smart session manager was modeled off.

Docs for using the Safe7579 adapter Safe7579 – Rhinestone Docs

1 Like

Safe social recovery approval account diversity

When distributing Safe approval accounts across people and/or organizations Safe approver diversity is important. That is to coordinate multiple providers of hardware and software approval accounts that are used.

Save approver diversity is important for similar reasons as Ethereum client and validator diversity in that no one issue with a provider can cause total loss of the Safe.

High performing diverse options builds resilience

  • This will improve security for individual and organizations by making their recovery options more resilient
  • Having a diverse set of Safe approval account types for a Safe is just as important as having client diversity for the Ethereum ecosystem
  • If too many of one account type are used as approvers it creates a potential critical issue. An issue with one account type could result in a total loss of all Safe assets and digital accounts.

Desired characteristics of approval account providers

Open source

Both the frontend and backend code is publicly available

Platforms

  • Available on Firefox browser or desktop (Linux, Windows, and macOS) with WalletConnect, and mobile Android and iOS
  • Firefox is important because it adds the highest standard of resilience as it is not dependent on Chromium like the majority of web browsers
  • Apps made for Firefox will most likely also be available on Chromium based browsers
  • Future research can be done specifically for Chromium based browsers if useful

Self recovery independent of a service provider

Self recovery is possible independent of a service provider or 3rd party

Sustainable business model

There is a sustainable business model which is important for the longevity of the service for users

Good user experience (UX) with Safes created from the native app app.safe.global

  • Basic actions: Create action, approve, confirm onchain
  • Platforms: Web/desktop and mobile
  • Network support and management switching between layer 2s (L2s)
  • Account management switching between multiple seed phrase based accounts
  • Coordination with notification management and messaging

Strong team

  • Location and considerations related to those jurisdictions around rule of law, property rights, privacy, freedom of speech, etc.
  • Work experience

Audits

Public audits have been done and are available

Reputable investors

Fear, uncertainty, and doubt (FUD)

There is little supporting evidence to support FUD and/or reasonable explanations

mikedemarais.eth, the cofounder of Rainbow shared a great perspective on the value of audits for externally owned accounts (EOAs) compared to smart contract accounts like Safe.

we have not pursued audits since then bc in our minds audits of regularly updating codebases is not very useful for anybody. wallet apps like Rainbow regularly push updates and make large changes to the codebase, any audit would be immediately obsolete the next time the app gets an app store update.

smart contract wallets on the other hand def are worth auditing

:rainbow: Rainbow – Good option to diversify Safe approval accounts

Rainbow meets most of the important desired characteristics of approval account providers outlined.

  • When distributing Safe approval accounts across people and/or organizations Safe approver diversity is important. That is to coordinate multiple providers of hardware and software approval accounts that are used.
  • This will improve security for individual and organizations by making their recovery options more resilient.

Here are some of the resources used to research approval account providers

Desired characteristics of approval account providers

Open source

Both the frontend and backend code are publicly available on GitHub

Platforms

Available on Firefox Beta and Chrome based browsers, Android, and iOS

Self recovery independent of a service provider

Self recovery is possible independent of a service provider or 3rd party using the 12 word recovery phrase

Good user experience UX with Safes created from the native app app.safe.global

  • Basic actions: Create action, approve, confirm onchain
  • Platforms: Web/desktop and mobile
  • Network support and management switching between layer 2s L2s in the web app
  • Account management switching between multiple seed phrase based accounts

Strong team

  • Distributed across the United States US, New York, Boston, Miami, Los Angeles, Bentonville, etc.
    • The US has been hostile to crypto through enforcement actions against companies without clear legislation
    • However the US has a clear rule of law especially compared to other countries and crypto companies have been winning court cases the past few years
    • The US has freedom of speech and stronger property rights compared to other countries
  • Experience from ConsenSys, Stripe, Amazon, eBay, etc.
    • These companies and products are used by millions of people providing easy and reliable experiences

Reputable investors

Alexis Ohanian, the Reddit cofounder’s investment company, Seven Seven Six, led an $18 million investment round in 2022

Fear, uncertainty, and doubt FUD

No specific items related to Rainbow have been found

Research to be done

Areas for myself and/or others to follow up on

Manage networks on mobile

Is it possible to manually switch networks in the Rainbow Android mobile app the same way it works in the web app? I could not find a way to do so.

Firefox app security

  • Double checking that the Rainbow Firefox beta app is secure to use?
  • According to Rainbow’s “Developer comments” they say “Rainbow for Firefox is currently in Beta. Your wallets are fully secured and protected, but Firefox currently suffers from performance issues related to modern extension architectures. Our team is hard at work addressing these limitations with Firefox and the broader industry to improve your user experience.”

Audits

Sustainable business model

  • I estimate fees are generated through making in-app actions and services like trading, staking, depositing into liquidity pools, etc.
  • More research needs to be done to learn if and how profitable this is.

Future consideration of Chrome based Safe approval accounts

  • Firefox is important because it adds the highest standard of resilience as it is not dependent on Chromium like the majority of web browsers
  • Apps made for Firefox will most likely also be available on Chromium based browsers
  • How dependent is Brave on Google? That is are there any core tech dependencies Google provides to Chromium, E.g. Hosting code libraries, infrastructure, etc. that Brave and others rely on or is Chromium fully runnable/deployable on its own?

Social apps secured with Safe sign in with MetaMask

MetaMask has new delegation features. I discussed with Dan Finlay at Edge City today the possibility of adding future features to support delegating access to a MetaMask approver account for specific access like signing into social apps.

If I’m a user that has a MetaMask as an approver account (1 of N) for my Safe I’d like to delegate specific access to it to make using apps secured by my Safe easier.

For example my Safe owns ahurwitz.eth that I use to sign up for Converse messaging with. However, when I sign in, in the future I don’t want to sign X of N transactions to use the app. Therefore I can delegate access to my MetaMask to read|write in Converse without making any ownership decisions like transferring the owner of the account, deleting account, etc.

I’ve outlined a few other strategies for this in the past years: đŸ«±đŸ»â€đŸ«ČđŸŒ Crypto account access control - HackMD

TLDR “Secured by Safe, easy to use on all devices with MetaMask”

Resources

1 Like