Implementation ideas

[olasunkanmi-SE]

Tiered Membership DApp

Overview

graph TD
    A[Super Admin] -->|Deploys Contracts| B(MembershipManager)
    A -->|Mints| C(ERC20 Token)
    B -->|Creates| D(MembershipNftToken)
    B -->|Creates| E(AttendanceNftToken)

    F[Admin] -->|Creates Membership| B
    B -->|Mints & Transfers| D
    B -->|Transfers| C
    F -->|Creates Event| B

    G[User] -->|Signs Up| F
    F -->|Transfers| C

    G -->|Attends Event| F
    F -->|Mints & Transfers| E
    F -->|Transfers| C

    H[Time] -->|Triggers| I(Membership Renewal)

Tiered Membership DApp is a decentralized application that allows organizations to create and manage tiered membership programs using blockchain technology. The application leverages smart contracts to handle membership creation, event management, attendance tracking, and loyalty rewards.

Features

• Tiered membership system
• Event creation and management
• Attendance tracking with NFT tokens
• Loyalty rewards using ERC-20 tokens
• Time-bound memberships with renewals
• Governance token distribution

User Stories

As an Oracle (System Initializer)

1. I can deploy the smart contracts for the membership program.
2. I can mint a certain amount of ERC-20 tokens to be used for governance and loyalty rewards.

As an Admin

1. I can create different types of memberships by transferring ETH to Oracle.
2. Upon creating a membership, I receive:
   • An ERC-721 NFT representing the membership
   • A certain amount of ERC-20 governance tokens
3. I can create events and link them to specific membership tiers.
4. I can mint attendance NFTs for users who attend events. Proof of attendance
5. I can transfer ERC-20 tokens to users as loyalty rewards.
6. My created membership is time-bound and requires renewal in certain intervals.

As a User

1. I can sign up for a membership by transferring ETH to the Admin.
2. Upon signing up, I receive a certain amount of ERC-20 governance tokens from the Admin.
3. I can attend events based on my membership tier.
4. When I attend an event, I receive:
   • An ERC-721 NFT as proof of attendance
   • ERC-20 tokens as a loyalty reward, depending on the admin's generosity
5. My membership is time-bound and requires renewal.

Technical Specifications

• Smart Contracts: Solidity
• Token Standards:
  • ERC-20 for governance and loyalty tokens
  • ERC-721 for membership and attendance NFTs
• Development Framework: Foundry
• Frontend: React.js with ethers.js for blockchain interaction

Business Rules

• Users and authority can extend, cancel, terminate, and destroy membership
• Admin can update membership
• Membership can be bought or granted by admin
• Membership (NFT) is soul-bound, meaning nontransferable.
• Membership Expires.
• The admin can expire membership in case of cancellation
• Identify user membership status. Active or Expired. Gate contents based on user membership status

Further functionality

Staking.

• Users and admin can stake their tokens to support the DAO

[isabelle-pundix]

Architecture suggestion:

1. Proxy Contract

• Upgradeable proxy that delegates calls to the MembershipManager implementation contract
• Stores state data for the contract (user memberships, event details)

2. MembershipManager Contract (Implementation)

Membership Creation

• Receive ERC20 token payment & mint SBT (ERC721) to user
• Each SBT contains an expiry timestamp which is checked during any interaction

Membership Renewal

• Receive ERC20 token payment & update SBT expiry timestamp

Event Signup

• Validate the user's membership tier and expiry status before event sign-up
• User Uses ERC20 received on signup to register for events as per the event entrance fee
• Use internal tracking to manage event participation & capacity

Attendance Rewards

• Mints attendance NFT using ERC721Factory upon event attendance

3. SBT Contract

• Only callable by MembershipManager to mint a SBT token/ renew the expiry timestamp

4. ERC721Factory Contract

• Deploys unique ERC721 tokens for different event attendance
• Keeps track of all deployed ERC721 contracts to make it easier for MembershipManager Contract
• Allows additional logic to be added to each ERC721 contract at deployment (e.g., SBT, metadata etc)

5. ERC721Implementation Contract

6. ERC20Token Contract

• Governance token used within the DApp, used to pay for events etc.

See image below for simplistic architecture:

[olasunkanmi-SE]

1. Let's take a simpler approach by avoiding the creation of upgradeable contracts, because I doubt we will have different versions of the contracts.

[halink0803]

@isabelle-pundix @olasunkanmi-SE we should finish the design and start working on the code. I think one of you can make a final design, then separate the tasks.

[olasunkanmi-SE]

Here is the create new membership contract workflow.

Create Membership

struct Membership {
        string name,
        uint256 duration,
        uint256 maxSupply,
        uint256 price
}

The membership contract should be able to

• Create new Membership.
• keep a record of membership sales.
• Query membership sales

Required

• SoulBoundNFTs Contract
• EthTransfer Contract

[olasunkanmi-SE]

@halink0803 @isabelle-pundix @jshekhawat @anshugarg401

[olasunkanmi-SE]

Next

• User Subscribe to Membership (Membership Subscription contract)
• User attends a membership event (Event Management Contract.)

[isabelle-pundix]

@halink0803 @jshekhawat @olasunkanmi-SE @olasunkanmiraymond @anshugarg401 here's the implementation overview we discussed today! (@jshekhawat feel free to add on architecture diagram of multisig contract).

as discussed, here's the workload split: @halink0803: Event Management contract @jshekhawat: ERC721 & Multisig contract @olasunkanmi-SE, @anshugarg401 and myself: Membership Manager

Timelines: Smart contract + Foundry test cases: 19 Nov (due on 21st Nov)

[olasunkanmi-SE]

The Membership Manager Contract has a dependency on ERC721 & Multisig contract. How soon can we get this done @jshekhawat cc @halink0803 @anshugarg401 @isabelle-pundix

[jshekhawat]

I will do it today, but realistically it doesn't have a dependency, you would be coding against the interface of ERC721. When you would be initializing the constructor you would dynamically be setting the address. like this:

IERC721 _membershipProvider = IERC721(_address);

and you can code against the interface:

https://docs.openzeppelin.com/contracts/3.x/api/token/erc721#IERC721Metadata

Please make sure that the token metadata would be in this format in json, that you should upload somewhere:

{
    "title": "Asset Metadata",
    "type": "object",
    "properties": {
        "tier": {
            "type": "string",
            "description": "membership tier"
        },
       "expiry": {
            "type": "string",
            "description": "membership expiry time"
        },
        }
    }
}

After uploading you should call the method with this signature:

function safeMint(address to, uint256 tokenId, string memory uri)
        public
        onlyOwner
    {
        _safeMint(to, tokenId);
        _setTokenURI(tokenId, uri);
    }

Also, the multisig is not a contract but an address and you will interact with it in the same manner as an EOA. Underneath that address will run gnosis safe for which I have already asked for your addresses: