[SEP 34][OBRA: Strategy 2] Resource Lock Module - Cometh & Gnosis Guild & OneBalance

[Draft] [OBRA] Resource Lock Module - Cometh & Gnosis Guild & OneBalance

Abstract

The Ethereum network transitioned to a rollup-centric roadmap in 2020. This has resulted in an abundance of blockspace, but has resulted in a broken cross-chain UX. Users today have to either wait 10s of minutes or pay 10s of dollars to execute a cross-chain transaction.

This proposal is to develop a new module on top of SAFEs which makes cross-chain interactions instantaneous. This module enables resource locks in SAFEs and removing cross-chain friction.

Aligned strategy

Which pre-approved strategy is this initiative driving forward?

Strategy 2: Foster Module Ecosystem

Funding request

What resources are being requested from SafeDAO in USDC?

75k USDC

If applicable, upfront funding

Indicate if upfront funding is needed. Refer to 'Payout’ under [Get funding from SafeDAO] for lump sum payment options.

N/A

Relation to budget

State the requested funding as a percentage of the total initiative budget (e.g. if you ask for 50k for Strategy 1: 25%)

33%

Metrics and KPIs

Which metrics and KPIs will the initiative be measured against?
  1. Increase in cross-chain SAFEs with Resource Lock Mod enabled.
  2. Increase in TVL in Safes with Resource Lock Mod enabled
  3. Increase in Total number of Safes with Resource Lock enabled
  4. Increase in developer engagement with Resource Locks
  5. Increase in network penetration of SAFE (total number of networks where SAFE is used)

Initiative description

What is the initiative about?

The Ethereum network has adopted the rollup centric landscape for scaling itself. Although this has resulted in abundance of blockspace (we can one click deploy a new L2 using RAAS) cross-chain UX is the bottleneck now. Gone are the days of the last DeFi summer when everyone was experimenting with blockchains at scale and retail interaction with EVMs were seamless.

An Ethereum user today needs to hold balances in different EVM chains, spend 10s of dollars or 10s of minutes moving those balances to a target chain and perform the action that they want to do. Causing significant drop-off or migration of retail users to the Solana ecosystem.

A cross-chain interaction today comprises of three core steps.

  1. Input transaction on origin chain: The user locks their state and makes a request in an escrow contract or pings the bridge contract on the origin chain.
  2. Waiting for finality of the input transaction: A trusted third party either a L1→L2 bridge (Optimism Bridge, Arbitrum bridge), an validator enabled Arbitrary Message Bridge (LayerZero, Wormhole) or a solver network (Across, UniswapX) waits for finality on origin chain.
  3. Output transaction on target chain: After waiting for finality the trusted party satisfies users request on the target chain.

Today step 2 i.e. waiting for finality is the cross-chain UX bottleneck. OneBalance introduces the concept of credible accounts:

Smart Accounts + Resource Locks = Credible Accounts

Using resource locks smart accounts can lock their state at the speed of signing removing the need to wait for finality and unlocking instantaneous cross-chain UX.

After resource locks the solver on the target chain can instantaneously satisfy the users intent on the target chain, without waiting for finality and decoupling the input and the output transaction.

We already have a host of partners ready to design, build and distribute credible accounts across the EVM ecosystem. This module is a way to convert SAFEs into credible accounts.

  1. List of partners
  2. How we will work together

Current status

Does the offering (product/service) already exist or is the funding used to create it?

The design for Resource Lock Mod contracts is ready and discussed with Gnosis Guild and OneBalance team. We need the grant to:

  1. Implement the design in solidity
  2. Get the module audited
  3. Integrate Resource Lock Module in Safe Wallet and Safe Core SDK

Risks

What risks does the initiative entail?

The risks involved are implementation and execution risks. Given the experience of author teams the risks should be minimal.

Timeline and milestones

Provide a detailed timeline or roadmap, include key milestones
Week Focus Outcomes USDC $SAFE
1-4 Design, Documentation and Development Development of Module contracts 25k N/A
5-8 Auditing the module Auditing the module 50k N/A

Initiative lead

Who is the accountable initiative lead? (individual or organization)
  1. Cometh
  2. Gnosis Guild
  3. OneBalance

Team

How many individuals in total will be working on this initiative and what role do they have? Please provide a brief background of the team members, highlighting their relevant experience and expertise

We would have 1 full time engineer working on this module, and will also share architecture design resources from the three teams.

Additional support/resources

Are there any resources (non-financial) requested from the Safe Ecosystem Foundation or the core contributors?

TBD

Implementation dependencies

Does the implementation of this initiative require any prior changes in the current governance processes, e.g., updates to the governance framework, or have any other dependency? If yes, please specify these. *Note that the funding of the initiative will be dependent on the approval and (if needed) successful implementation of such necessary governance modifications or any other dependency.*

The Resource lock Mod depends on the Delay Mod.

1 Like

Thanks for taking the time to write your proposal!

Please note some important deadlines in the timeline for this sprint. It officially starts today, July 8th and you have until Monday, July 22nd at 23:59 UTC to get signal from at least 3 delegates/guardians with cumulative voting power of 60K / total from all three (details outlined in our governance hub and as exemplified here).

While we usually have Phase 1 proposals present at the Governance call (next Wednesday, July 17th at 16:00 UTC), since you have already presented in the last sprint, this is completely optional. If you would like to join and present again or something new, please let me know so I can add you to the agenda.

1 Like

I am a Safe Guardian with sufficient voting power . I believe this proposal is ready to move to a Snapshot vote.

1 Like

Hey @Ankit_Chiplunkar Few notes/questions.

  1. The funding request is 100K, however the request must fit the remaining budget, which is 90K.

  2. Under Current Status:

Proposals that require integrations/dependencies on Safe Wallet and Safe Core require input/sign-offs from these teams. Core and Wallet will evaluate the integration and leave comments here.

1 Like

I believe we need more information - as well as need to ensure this is updated to be within the budget remaining in this strategy.

I want to know who will audit this - do you have a firm in mind? Can you provide a little more insight in use of funds and how those are used?

Thanks for the proposal @Ankit_Chiplunkar. I’m Chris working as product manager on Safe{Wallet}. As I can see from the proposal you intend to integrate your solution into Safe{Wallet}. From the proposal it is not yet clear to me how this would look like concretely for the user. Could you elaborate a little bit? Would especially be interested in some concrete user benefits and user flows to understand how this would work and how the benefits would play out and furthermore how the integration would take place from a technical point of view (i.e. I assume that the user would need to enable the module but would be great if you could elaborate on that one too).

2 Likes

Listening to the feedback, we have removed the last requirement and reduced the budget to fit in the grant.

@kdowlin we dont have a firm in mind yet. But the audit budget was defined after looking at similar grant proposals.

1 Like

Hi @Ankit_Chiplunkar, disclaimer: now the asking/commenting reflect my personal opinion and not the one of my employer (since you removed the Safe{Wallet} integration).

I would still like to know how the user flow would look like and what the benefits concretely would be for a user. Furthermore, are you planning to build a Safe app or how are you envisioning the module being added to a Safe?

2 Likes

I would encourage you to seek bids from audit firms prior to submitting a request vs leveraging other proposal amounts isn’t likely sufficient given each audit is based on complexity.

Hey @Ankit_Chiplunkar also check OP.

These just released a subsidised audit grant program, which would lower your ask to 25k based on the stated budget and audits could be done once a POC is delivered.

2 Likes

@kdowlin We have a few firms like (openzepplin, certora) but they cannot give us a quote till the codebase is stablized. We will publically announce the selected team and their quote.

If the audit is less than proposed amount then we will give back the amount. If its more then we will find other sources or pay from team funds.

@chris_Safe reaching out via DMs

I am a Safe Guardian with sufficient voting power. I believe this proposal is ready to move to a Snapshot vote.

I am a Safe Guardian with sufficient voting power, and I believe this proposal is ready for the Snapshot vote.

I am a Safe Delegate with Sufficient Voting Power. I believe this proposal is ready to move to a Snapshot vote.

Chain abstraction is the most important problem to solve in the Ethereum ecosystem right now. Would love to see these great teams tackling it as a Safe module. :+1:

I am a Safe Delegate with Sufficient Voting Power . I believe this proposal is ready to move to a Snapshot vote.

I am a Safe Delegate with Sufficient Voting Power . I believe this proposal is ready to move to a Snapshot vote.

Your proposal has reached sufficient signal to move to Phase 2: Voting. It will be live for voting on Snapshot on Wednesday, July 24th.

Hey all, Kurt here from Rhinestone. We’re building infra and tooling for an open module ecosystem that is smart account agnostic. Safe is an investor and partner. Recently, we co-authored ERC-7579 and co-developed an adapter with the Safe team (linked below).

I didn’t expect this proposal to move to a vote, but given the developments, I wanted to share the below points in this public forum.

TL;DR:

  1. A resource lock module is already in development for the Safe Ecosystem and will continue into production independently of this proposal.
  2. The requested grant is far too high, given our experience. This has already been noted, but I have provided some benchmarks below.

At Rhinestone, we have a working prototype of an ERC-7579 resource lock, and we’re currently ideating our approach to share it publicly soon. This has been communicated with Safe and we plan to collaborate on this project. This module is already compatible with Safe (via the Safe7579 adapter) and we intend to work closely with the relevant parties to ensure chain abstraction can be unlocked within the Safe ecosystem, along with other interesting product experiences that require resource locks.

Regarding the requested grant, we have extensive experience building and auditing modules, including our core modules and the recent zkEmail recovery module (links below). We typically see audit fees of 4k to 10k USD per module. Based on our current work, we have no reason to believe that resource locking will be more complex than any of the existing modules we have worked on and audited.

Rhinestone Core Modules: core-modules/src at main · rhinestonewtf/core-modules · GitHub
ZK Email recovery module: email-recovery/src/modules at 4e7031693d8e97cfcbc42b7d063a748a0a53b952 · zkemail/email-recovery · GitHub
Safe ERC-7579 adapter: Safe and ERC-7579 – Safe Docs

3 Likes

The proposal is live on Snapshot. Voting starts Wednesday, July 24th and runs until August 5th.

@Kurt_Larsen could you share who’s doing module audits for $4k-10k :eyes: — like @Ankit_Chiplunkar said, if the audit can be completed for less than the stated amount by a reputable auditor, those excess funds will not be paid out or will be returned. for reference, the ZK Email team was quoted $75k, and the stated amount is in line with our experience.

I think it’s great that multiple resource lock implementations are being developed, as this will ultimately benefit the Safe ecosystem. each implementation has its own idiosyncrasies and may be suited to different contexts. the more the merrier!

1 Like