project screenshot 1
project screenshot 2
project screenshot 3
project screenshot 4

Safe Invaders

Secure and gasless collaboration for smart contract development. No more key sharing or multi wallet funding.

Safe Invaders

Created At

ETHGlobal New York

Winner of

🥉 XDC Foundation — Best Use

🏊‍♂️ Scroll — Pool Prize

💡 Gnosis Chain — Most Innovative dApps

🏊‍♂️ Arbitrum — Pool Prize

Project Description

Currently, smart contract dev teams either share a single deployment key or have to manage funds and permissions for several developer wallets. Using 4337 AA, we centralize funds and permissions in a single smart account. This increases the security and operational efficiency of the deployment lifecycle.

  1. Create a project (create a Safe)
  2. Invite teammates (add owners to Safe)
  3. Fund project (fund Safe)
  4. Any team member can deploy (developer signs a user op)

How it's Made

Safe

Safe is a battle tested framework which natively supports the concept of owners/team members. It also has a module system that we can use for the various extensions we are planning below.

A 4337 compliant smart contract was written that is deployed globally for all projects. When new projects are created, they are connected to the contract as both the Safe's fallback handler and as a module.

Bundlers

Tested with Biconomy, Pimlico, and StackUp

Future work

  • ENS subnames: Create subnames for each deployment similar to how each Vercel deployment has a different subdomain.
  • Complex deployments: Manually uploading compiled code, which we demo for the hackathon, is a simplified and awkward flow. Safe Invaders should support multi-contract deployment that is more tightly integrated into existing web3 dev tools.
  • Finish deployment logic: Our 4337 implementation was not complete. We were not get CreateCall to work through a user op on the Safe. We also use a simplified fallback handler that does not perform all signature checks.
  • Cross chain deployments where the safe acts like a paymaster: Gasless deployments across multiple chains.
  • Increase trust: Integrate with services like Lens that can provide context about the developers that deploy.
  • Promotion logic: Currently, any developer can unilaterally deploy. This should instead be configurable so that at least N dev signatures can be required. Or even allow DAOs to control which ENS subnames are delegated to official ENSs.
background image mobile

Join the mailing list

Get the latest news and updates