---
# System prepended metadata

title: clique finance notes

---

# clique finance notes

## High-Level Open Questions

- What will the yield strategy be? Yax Metavault & Alchemix 3crv 
- Are we building a mobile app or web app? or both? Both
- How much data will we store in web2 databases vs in smart contract storage? (see the example below re: inviting friends to cliques) I don't know the answer to this 
    - gas costs vs centralization 

More detailed open questions are highlighted below.

## Requirements / description of MVP

- Mobile App
    - goal: minimalist UI that allows the user to accomplish basic tasks related to account/wallet management, and social/clique management
    - implementation:
        - use React Native for cross-platform support by default
        - tbd: should we target ios-only for MVP?
    - features:
        - account creation using mobile number
            - secure login using number/password or biometric login
        - automatic eth wallet generation on signup
            - stored encrypted locally
            - allow exporting private key
            - biometric authentication for all transactions
            - tbd: optional hosted wallet ("backup" - could even use icloud on ios)
        - social / clique management:
            - profile editing - set your username and avatar
            - create a clique
            - invite user to clique
                - tbd: should we include "add friend" and friends list (not MVP)
            - deposit/withdraw crypto
                - tbd: decide fiat on ramp method (apple pay like rainbow?)
                - tbd: decide what cryptocurrencies should we support from the user's perspective? (stable coins only?)
            - View stats and balances

- Backend / API
    - Web2 Endpoints
        - **create_account**(...)
        - **get_contract**(...)
            - used to generate web3 txs for:
                - **create_clique**(...)
                - **invite**(user_id, clique_id)
                    - note: we need to decide how the invite flow will work since it affects what data is stored......some options include:
                        1. Allow users to invite friends using the phone number or username, and store a mapping of username → address in the contract (no web2 storage needed)
                        2. Make **invite** a web2 API endpoint instead, and allow user to invite with username / number. Add the invitee (public eth address stored in User table) to the clique on behalf of the user.
                        3. Make a web2 endpoint **get_address(username)** and let the user send the TX from the app  (similar to #2)
                        4. Only allow inviting based on eth address (no contract storage or web2 storage needed). This requires users to know their public address and share it, which we should avoid for ease of use.
                - **deposit**(clique_id)
                - **withdraw**(clique_id, amount)
    - Data Model
        - User table
            - username (key) and password
                - tbd: should we use phone number or username as user ID?
            - ETH public address
            - profile info
            - (opt-in) encrypted private key
- Smart Contracts / Yield Strategy
    - todo - describe yield strategy
    - todo - describe storage fields we need (cliques, membership)
    - tbd: should we use an address whitelist?