AllowList Stamp MVP

[Jkd-eth]

User Story:

As a partner, I want to create a custom stamp that pre-approves users based on a predefined list of addresses, So that I can streamline the verification process for trusted users in my campaign.

Acceptance Criteria

TICKET ¹ -- Step 3 -- 3 .s Visibility on Custom Dashboards GIVEN a user is accessing the custom dashboard WHEN the custom dashboard is loaded THEN the AllowList Stamp should be visible only on custom dashboards where the product team has set a score weight greater than 0 AND it should not be visible on the default dashboard, maintaining 0 weight to avoid interfering with standard processes.

TICKET ² -- Step 1 -- 5 .s Score Weight Assignment GIVEN the product team is configuring the score weights of the partner's custom dashboard WHEN the product team sets a score weight for the stamp THEN the system should accept any two decimal number greater than 0 as the score weight.

Uploading Address List GIVEN the product team has received a list of addresses from a partner WHEN the product team accesses the Django admin interface THEN the product team should be able to upload a CSV file containing a simple list of addresses AND the system should validate the format and store the list securely.

TICKET ³ -- Step 2 -- 5 .s Verification Process GIVEN a user clicks the Verify button on a custom dashboard WHEN the system checks the user's address against the uploaded list THEN if the address is on the list, the user should be awarded points as per the configured score weight AND if the address is not on the list, an error message should be displayed: "You are not on the allowlist of this campaign."

Integration with Web3 1-Click Flow GIVEN a user is undergoing the web3 1-click verification process WHEN the process includes the AllowList Stamp check THEN the system should seamlessly integrate this check within the existing onboarding flow.

Product & Design Links:

• Placeholder for Figma design: [Figma Placeholder Link]
  • This placeholder will be used to develop the visual representation of the AllowList Stamp and its placement in the user dashboard.

Tech Details:

• Admin Interface: Implement CSV upload functionality in Django admin for the product team to upload address lists received from partners.
• Score Weight Configuration: Allow the product team to set a numeric weight with two decimal precision greater than 0 on behalf of the partners.
• Verification Integration: Incorporate the AllowList Stamp check within the established web3 1-click verification flow.
• Error Handling: Display a specific error message if a user is not on the allowlist.

Open Questions:

• [ ] What should the design for the AllowList Stamp look like?
• [ ] Into which of the existing stamp categories should the AllowList Stamp fit, or should a new category be created?
• [x] How do we handle storage across different data substrates (Ceramic, Onchain), How do we make the provider names legible so the credentials have legible Metadata for integrators to understand e.g., "This is an address trusted by Octant"?

Notes/Assumptions:

• Future customizations (e.g., icon and text changes) are not in scope for the MVP but will be considered for subsequent phases.
• Security measures for handling address lists will follow existing protocols as no additional measures are required.
• The design will be iteratively developed with input from the product and design teams.
• This needs to be completed by mid-June for Octant.

[nutrina]

DRAFT

The changes required:

1. new stamp payload
   • we need to somehow identify that: a. it is another stamp type b. also reference the allowlist
2. allow uploading allowlists as CSV file in admin. CSV fields: address
   • CSV files should be linked to account
   • allow linking one or more allow lists to a custom dashboard
3. implement endpoint to allow checking if an address is in an allow list or not
   • inputs: eth address, dashboard id
   • this should check all allowlists linked to dashboard
4. implement issuance of the new stamp in the IAM
5. new parameter in requests to the IAM: scorer id
   • this needs to be passed through into the verify method for providers
6. implement provider that issues allowlist stamps
   • this new stamps provider(s) should not be written on chain yet (skip these stamps)
7. create new schema for compose-db for the new stamp
8. deploy the new schema to compose
9. implement writing the new stamps to compose
10. support for writing the stamps to the blockchain

Related topics:

• stamp revocation - do we need this?

[erichfi]

Split this work into three issues:

• https://github.com/gitcoinco/passport/issues/2531
• https://github.com/gitcoinco/passport/issues/2532
• https://github.com/gitcoinco/passport/issues/2533