Futureverse Wallet

This repo includes implementation of EIP725 based wallet and an account registry contract (to register wallet for new users).

Account registry

Wallet

Consists of 2 contracts - which work together to implement the ERC725Account spec:

• KeyManager - based on LSP6
• ERC725Account - based on LSP0

KeyManager

Responsible for permissions (ERC725Y substandard). A manager/owner and entrypoint for the ERC725Account (controls the ERC725Account contract).

Why do we need this?

• allows the ERC725Account contract to be managed by multiple addresses (since ERC725Account is only managed by a single address)
• enables de-coupling of the permissions logic of the ERC725Account contract
• enables upgradability of the permissions logic (KeyManager)

KeyManager standards - ERC165 0xfb437414

• ERC165
• ERC1271

ERC725Account

Responsible for execution (ERC725X substandard - for calls, contract deployments).

Management of the ERC725Y functionality (data key-value store) is provided by the owner KeyManager contract.

ERC725Account standards - ERC165 0x66767497

• ERC165
• ERC725Y
• ERC725X
• LSP1-UniversalReceiver
• ERC1271
• LSP14Ownable2Step
• LSP17Extendable

note: This bytes4 interface id is calculated as the XOR of the interfaceId of the following standards: ERC725Y, ERC725X, LSP1-UniversalReceiver, ERC1271, LSP14Ownable2Step and LSP17Extendable.

• Additional docs: https://docs.lukso.tech/standards/universal-profile/lsp0-erc725account/#what-does-this-standard-represent-

Architecture

• The FuturePassIdentityRegistry is the core contract which is responsible for creating user digital identities/accounts
  • It is deployed via TransparentUpgradableProxy pattern - to support future upgrades
  • note: We do not use hardhat upgrades lib to deploy the proxy, instead an EOA is simply set as the proxy owner (instead of a contract)
• The FuturePass is a modified version of the LSP0/ERC725Account contract, this is the digital identity contract (responsible for on-chain actions/calls)
  • This is deployed as a logic contract (implementation which a beacon proxy would point to)
• The FuturePassKeyManager is modified version of the LSP6 contract, this is responsible for the permissions logic of the FVIdenttity contract
• UpgradableBeacon - 2 upgradable beacons are deployed, which point to FuturePass and FuturePassKeyManager implementation contracts
  • The beacon proxy pattern is used here (described here), this allows admin to upgrade all user accounts (FuturePass and FuturePassKeyManager) in case new functionality/fixes are to be introduced. This is a cost-effective approach to support mass-upgrades on all user accounts (with single TX)
• The register(address) function is used to create new future pass for an address
  • This creates a BeaconProxy pointing to the FuturePass upgradable beacon; inheriting logic of the FuturePass contract
  • This also creates a BeaconProxy pointing to the FuturePassKeyManager upgradable beacon; inheriting logic of the FuturePassKeyManager contract
  • The proxies are setup such that the user's FuturePassKeyManager proxy points to the FuturePass (target) and the FuturePass proxy owner is set to be the FuturePassKeyManager proxy contract
    • The owner of the FuturePassKeyManager proxy is the EOA (address being registered)
      • The FuturePassKeyManager proxy contract is the only entrypoint into the FuturePass proxy contract (user's digital identity)
  • note: The proxies only hold state of the respective contracts, they are upgradable (upgrading beacon upgrades FuturePass contract logic)

Deployment procedure

The deployment script will perform the following actions:

sequenceDiagram
  title Contract deployment

  participant Admin as Admin EOA
  participant TRN as Root Network

  Admin ->> TRN: Deploy FuturePass logic contract
  Admin ->> TRN: Deploy FuturePassKeyManager logic contract
  Admin ->> TRN: Deploy Utils Library
  Admin ->> TRN: Deploy FuturePassIdentityRegistry logic contract with linked Utils library
  Admin ->> TRN: Deploy TransparentUpgradeableProxy with FuturePassIdentityRegistry, initialize upon deployment 
  TRN -->> TRN: deploy UpgradableBeacons, point implementations to FuturePass and FuturePassKeyManager contracts

Loading

User registration flow

sequenceDiagram
  title Account registration

  participant User
  participant Registry as FuturePassIdentityRegistry

  User ->> Registry: Calls register(address)
  Registry -->> Registry: Deploy BeaconProxy (pointing to FuturePass beacon impl)
  Registry -->> Registry: Deploy BeaconProxy (pointing to FuturePassKeyManager beacon impl)
  Registry -->> Registry: Initialize FuturePassKeyManager proxy with FuturePass proxy as target
  Registry -->> Registry: Initialize FuturePass proxy with FuturePassKeyManager proxy as owner (all permissions)
  Registry -->> Registry: Register FuturePassKeyManager proxy as the user addresses account manager
  Registry ->> User: Emit FuturePassRegistered and return FuturePassKeyManager (proxy) address 

Loading

Setup

Pre-requisites

• foundry must be installed

Install, Build, Test

Retrieve git submodules:

forge install

Build contracts:

forge build

Run tests:

forge test

Deployment

Copy the .env.example file to .env and fill in the required values.

cp .env.example .env

Note: Dummy values (private key and public address) for Alice have been provided.

Deploying to local network

1. Start local node (e.g. anvil)
2. Run command:

Hardhat:

yarn deploy:local

Forge:

forge script script/Deployer.s.sol:Deployment --fork-url http://localhost:8545 --broadcast

Prod deployment

Hardhat:

yarn deploy:porcini

Forge:

source .env
forge script script/Deployer.s.sol:Deployment --rpc-url $GOERLI_RPC_URL --broadcast --verify -vvvv

Note: The --verify flag will verify the deployed contracts on Etherscan. Note2: Forge cannot be used to deploy to TRN - due to issue

---

Testing

forge test -vvv

Gas golf

forge test --gas-report

1. Get gas results for unit tests as starting point
2. Make changes
3. Rerun gas tests
4. Compare results

---