AccGarda

A multi-asset Smart Account with configurable hack-resistance features including gasless guardianship, social recovery, time-delayed transactions and a simple frontend.

Comment

One-line description

A multi-asset Smart Account with configurable hack-resistance features including gasless guardianship, social recovery, time-delayed transactions and a simple frontend.

Disclosure

I had a lot of issues getting my code deployed to the TESTNET due to a lack of ETH and my own unoptimized contracts. Then once it got to the TESTNET (today 2pm) I found that I had issues with it that I'd never seen in my extensive local node testing. I ran out of time. Sorry I didn't get it fully working, but I'm submitting what I do have for consideration.

I also didn't get time to use Chainlink. I only really want to apply for the zkSync Account Abstraction prizes, so I hope this is acceptable, I thought it was because of the line in the overview page Hackathon overview page that says:

"For sponsor prizes, you do not have to use Chainlink - but to make your project as best as it can be using the materials here, it is recommended you do!"

Inspiration

AccGarda was inspired by the new features available in zkSync Era's account abstraction, which offered the opportunity to build a rich set of account management and protection capabilities direct into functionality deployed on the blockchain. Without this abstraction, functionality to improve hack-resistance and recovery needs to live off of the blockchain, which reduces what can be done, and how protective it can be.

The name comes from a contraction of "Account Guardian" and when I tried fun ways to shorten it, I liked how much "Acc Guarder" sounded like lake Garda, a feeling of calm that I want users to have when using a well designed smart account.

What it does

  • AccGarda is a smart account, i.e. a contract that holds assets on behalf of a user (the user interacts as though they are the account, but sign everything using their own wallet)
  • AccGarda has a social recovery mechanism, based on the concept of "Account guardians"
    • Account Guardians are other blockchain users that the account owner knows and trusts, and who can be trusted to act on their behalf
    • if a user loses their private key, or it gets revealed by an attacker, the user can propose to their guardians a new wallet address they want to use
    • they do this through the frontend app, which provides a link for the owner to share with the guardians
    • the guardians click the link, and follow the steps there to vote to approve the change
    • if enough guardians vote (there is a configurable threshold, e.g. 2 out of 3 guardians must approve) then the account ownership will change and will be owned by the replacement address
  • Unfortunately not working on testnet: The AccGarda account pays gas on behalf of guardians voting for changes - guardians do not need a balance to approve changes, they have gasless voting
  • AccGarda has hack resistance features based around the ideas of detection & response to attack:
    • AccGarda publishes events for critical actions to the blockchain, allowing the possibility to set up a monitoring solution that will notify the owner if a transaction or unexpected vote happens
    • AccGarda allows the owner to configure limits over what can be spent within a given time period (e.g. 0.05 ETH over 5 days), so if an attacker makes a transaction it must be smaller than the limit, and the owner will have 5 days to notice and take action (like social recovery) before any more can be spent
  • The risk settings are configurable by the owner at setup and can be changed in a safe manner:
    • The amount at risk can be changed per-token, e.g. a limit for ETH of 0.005 ETH, and a limit for LINK of 2 LINK
    • Settings that decrease risk (shorter time or lower limit) can be carried out immediately by the owner
    • Settings that increase risk need guardians to vote, as with social voting the user can share a link to ask the guardian to perform a gasless vote to approve (unfortunately the gasless vote itself not currently working on testnet)
  • To add convenience there are workarounds for the risk limits:
    • An owner can submit approval for a high-value time-delayed transaction, for any amount above the limit, and then wait the full risk measurement time window (e.g. 5 days) before being able to spend that approved amount
    • Again, the idea is that if the attacker does this, there is time to notice and respond
    • Alternatively, an owner can request "break-glass" emergency approval for an above the limit spend, and again they get a link, share it with their guardians and ask the guardians to use a gasless vote to approve the spend (unfortunately the gasless vote itself not currently working on testnet)

How I built it

AccGarda is based on solidity contracts using the zkSync tools and some openzeppelin libraries. The frontend is a Javascript REACT web app developed using Vite and deployed to a Firebase hosting project. The app is deployed at acc-garda.web.app

Challenges I ran into

I faced a range of technical difficulties and things not working as expected, as covered in brief above.

The more interesting challenges are in the product development / UX strand. How can I balance security & convenience? How can I cut down the number of settings users need to manage, in order to simplify but in ways that make the "safer thing easier". For example:

  • Forcing time-delay on all transactions is inconvenient, so allowing spends below a threshold without delays aids usability.
  • But if you allow smaller value transactions, you can't just allow an attacker to salami slice their way to taking all the assets - you must also limit spends over the same time window.
  • This lead me to the mental model of getting the user to think about "how much can I lose in the worst case" and "how long will it take me to notice something and respond"

A big challenge that I ran into that I didn't fully solve yet is in the "attack detection" strand. I have put events on all critical actions that happen with the account, but so far I didn't find any out of the box monitoring that a user can setup for themselves to setup a "notify me by slack / email whenever event x happens on address y". A lot of the existing solutions are developer-oriented designed to plug into another app, and some of the more user friendly ones didn't yet support the zkSync chains. This would be a key area to take forward.

Accomplishments that I're proud of

Although I didn't end up with a fully working app, I am pleased at how I stuck with it. I started this project far too late, but within 3 weeks, I have delivered something that I was quite proud of. As of 48 hours ago, it really looked as though I had no chance to deploy my code to the testnet, but I stuck with it and spent around 18 hours at the last minute refactoring my project to make it much more efficient to deploy.

What I learned

It's been great to see how separating the identity concept from the asset ownership concept at the blockchain layer allows for much more flexibility to solve user needs in a convenient way. It's nice to see L2 chains, like zkSync, using their freedom to diverge from the EVM standards to bake such concepts in whilst maintaining compatibility with EVM smart contract languages.

On top of this, in this project was the first time I used a range of technologies: zkSync itself, Vite, and it was the first time I made of such heavy use of Hardhat. I feel like I've learned a lot in all of these domains.

What's next for AccGarda

The elephant in the room is clearly "fix the thing!" I'm not sure exactly what that entails as the errors I have are somewhat baffling and didn't happen on my local chain, but only on the testnet.

Apart from this, it feels in a pretty good shape to actually try and get some people interested in looking at it. Do users like this kind of functionality? Is it usable, is it desirable, is it helpful? If there was demand to actually deliver something like this, then I would love to take it forwards, and try to deliver a user-friendly, desirable product.

If there is demand for a real product like AccGarda, then there's a wide range of things on the todo list:

  • Optimise the contracts some more to make the deployment cheaper and more feasible
  • Add proper monitoring of account events, allowing users to get realtime notifications if something happens behind their back
  • The UI deserves a lot more attention - More validation / error handling, and more polish & robustness generally
  • Add a feature so that the user can deploy a smart account direct from frontend (nearly did this, I just ran out of time)
  • Plus a range of other productionisation and robustness improvements, and if it ever made it to the real network it needs a security audit (or several)

Built With

Share this project:

Updates