meta: ERC-5564 and ERC-6538 Compatibility Tracking Issue

[mds1]

This issue tracks the required steps to build a version of Umbra that's compatible with the following two EIPs:

• ERC-5564: Stealth Addresses: Private, non-interactive transfers and interactions.
• ERC-6538: Stealth Meta-Address Registry: A registry to map addresses to stealth meta-addresses

EIPs

• Both EIPs are currently in the draft phase. We should share these with the community and get feedback, and work on progressing them from Draft -> Review -> Last Call -> Final. For convenience, the definitions of each phase are copied below from EIP-1.

  • Draft: The first formally tracked stage of an EIP in development. An EIP is merged by an EIP Editor into the EIP repository when properly formatted.
  • Review: An EIP Author marks an EIP as ready for and requesting Peer Review.
  • Last Call: This is the final review window for an EIP before moving to Final. An EIP editor will assign Last Call status and set a review end date (last-call-deadline), typically 14 days later. If this period results in necessary normative changes it will revert the EIP to Review.
  • Final: This EIP represents the final standard. A Final EIP exists in a state of finality and should only be updated to correct errata and add non-normative clarifications. A PR moving an EIP from Last Call to Final SHOULD contain no changes other than the status update. Any content or editorial proposed change SHOULD be separate from this status-updating PR and committed prior to it.

• Write contracts and tests.

  • ERC-5564 StakeManager.
  • ERC-5564 Messenger is StakeManager.
  • ERC-6538 StealthMetaAddressRegistry.

• Get contracts audited.

• Come up with deployment transactions for each contract that anyone can use on different chains.

• Deploy contracts.

Umbra

These ones need to be fleshed out more into discrete tasks, but for now here is a list of things that will need to be updated to be compatible with the new EIPs:

• The periphery contracts:
  • New contract to hold sent tokens for meta-transaction withdrawals, etc, perhaps named something like ERC5564Custodian. We can consider having this contract implement it's own toll, and our app can choose to only show sends that used this contract if spam becomes an issue. We can also think about alternative designs, such as sending directly to stealth addresses for tokens that support permit.
  • Update UmbraBatchSend contract.
  • Update UniswapWithdrawHook contract.
• umbra-js
  • We'll need to change interfaces so it's flexible enough to support non-secp256k1 schemes, so we can use this as an opportunity to rebuild umbra-js and ditch things like BigNumber in favor of native bigints.
  • Consider removing lots of functionality that I suspect isn't widely used, such as all the advanced mode stuff, and only support using the registry to start.
  • We should also consider "what features would umbra-js need to 10x stealth address usage and get people building on top of umbra?" (e.g. wallet integrations, etc). See if there's any good ideas here, and if so, we can consider building them out. For example a method that simply returns all stealth addresses (and balances) for a user could be very valuable for for someone building a privacy friendly wallet that uses stealth addresses / different accounts by default behind the scenes.
  • Maybe we can sponsor an ETHGlobal hackathon prize (or something similar) for someone to build something cool on top of umbra-js.
• The frontend
  • I think we should write a new one with next/wagmi to modernize + remove tech debt and clean things up.
• The backend
  • From what I hear the code is a bit messy and needs to be cleaned up, so we should consider just deploying a fresh backend in rust, that uses forge to simulate txs and query uniswap for oracle prices, to get more accurate, simpler estimates that don't rely on price APIs