Integrate Passport Model Based Detection API for QF rounds

[koday1]

Passport has released a new [beta] Model Based Detection (MBD) API.

It enables partners to protect access to their programs and analyze their ecosystem’s user base with a Passport-grade supervised machine learning model.

"This API is designed to return the results of model-based detection methods. During this initial beta phase, it will score ETH addresses against a single model that analyzes ETH mainnet transaction history against 50+ data features to identify if that address is likely Human or Sybil."

API Docs: [Beta] Model Based Detection API.pdf

We want to integrate this API to the Giveth Dapp to create a "double verification" system. I.e. if a user passes the MBD system, they will qualify for matching regardless of their Passport score. If they don't pass the MBD, then they need to verify their Passport score is above the threshold to count for matching.

This will reduce the overall effort required from users to ensure their donations are eligible for matching, as well as serve as an additional layer of Sybil defense.

@CarlosQ96 I assigned you to this issue, but we will likely need another issue for the FE work once we figure out how to integrate this API into our backend.

cc @laurenluz

[laurenluz]

Yesterday @CarlosQ96 @koday1 & I met and chatted about the implementation of this. This comment is break it down a little more.

• Need to integrate model based detection API into Giveth as a 1st check (before checking any passport stuff)
• Need to create a variable in our backend "minMBDscore" (or whatever we want to call it) that, if the user's eth address (when checked against the API) scores above the threshold for MBD, they "pass" and if not they "fail"
• Need to create a new table related to the user ("score models") that saves their scores & the date last checked
• We should "check" the user's address using the MBD API either (1) when the user clicks "check my eligibility" (design TBD) or (2) when the user makes their first donation to a QF project during a new QF round. (we will recheck each time there is a new QF round)
• If the user's score from the MBD API is above the threshold we set in the backend, they get all the "pass" messages (i.e. "your donation is eligible)
• if the user's score form the MBD API is below our set threshold, they fail, and then we check for their "passport" score (do an auto-refresh to check their score from the passport API), and give them the corresponding messages for their passport score.

does that sounds all right @CarlosQ96 ? did I miss anything?

[CarlosQ96]

Working on this!

[maryjaf]

• Need to create a new table related to the user ("score models") that saves their scores & the date last checked

• [ ] should this table be shown in admin? @CarlosQ96

[maryjaf]

• We should "check" the user's address using the MBD API either (1) when the user clicks "check my eligibility" (design TBD) or (2) when the user makes their first donation to a QF project during a new QF round. (we will recheck each time there is a new QF round)

• [ ] I think I haven't got the item 2 correctly , could you please add more description and how can I test it as an end user ?

I saw in figma after success donation the "check eligibility" button should be shown but I think the item 2 isn't exactly related to this , am i right? @CarlosQ96 @koday1

[maryjaf]

• [x] How can I check the MBD score of my wallet address directly ? to be sure when my user score be failed, this is a correct and expected result or not ? actually I need a reference to check the test result in dapp with it

[laurenluz]

should this table be shown in admin? @CarlosQ96

This is supposed to be a table in the backend, not in admin bro.

We should "check" the user's address using the MBD API either (1) when the user clicks "check my eligibility" (design TBD) or (2) when the user makes their first donation to a QF project during a new QF round. (we will recheck each time there is a new QF round)

I think I haven't got the item 2 correctly , could you please add more description and how can I test it as an end user ?

@maryjaf basically, at the start of a new QF round, if they user is making their 1st donation, we should automatically check their eligibility agains thte MBD system. if they pass (i.e if they have enough on-chain activity with that address that their score should be high enough... (no stamps)), the user would see all the "your donations are eligible to be matched" prompts without ever having to click the "check my eligibility" buttons.

It's like a fast-track.

The other way they could enter this "checking flow" is ... if they don't make an initial donation, but they DO click the 1st "one click check" buttons in the design.

In anycase, if they do not meet the requirements to pass the MBD score threshold, they will see all the "we need more info to verify your eligibility" and will need to verify their identity/score with gitcoin passport.

[laurenluz]

How can I check the MBD score of my wallet address directly ? to be sure when my user score be failed, this is a correct and expected result or not ? actually I need a reference to check the test result in dapp with it

@CarlosQ96 please help @maryjaf! :-D

[maryjaf]

How can I check the MBD score of my wallet address directly ? to be sure when my user score be failed, this is a correct and expected result or not ? actually I need a reference to check the test result in dapp with it

@Meriem-B has shared the api with me

[maryjaf]

• [ ] unfortunately all of my users have score 0 , and for exact testing related to "check visibility" flow I need an address with score

@Meriem-B changed score of some of my addresses in db but in this way also I couldn't simulate and check the exact e2e flow

[CarlosQ96]

• Need to create a new table related to the user ("score models") that saves their scores & the date last checked

• [ ] should this table be shown in admin? @CarlosQ96

Ill add this table, it will show it per qfround. I think its important to have it. Table already exists but its not visible

[maryjaf]

@maryjaf basically, at the start of a new QF round, if they user is making their 1st donation, we should automatically check their eligibility agains thte MBD system. if they pass (i.e if they have enough on-chain activity with that address that their score should be high enough... (no stamps)), the user would see all the "your donations are eligible to be matched" prompts without ever having to click the "check my eligibility" buttons.

@Meriem-B @CarlosQ96 based on this comment the behavior of system in this scenario isn't as expected:

• my score is more than threshold
• after doing a donation in QF round , the score check should be done automatically and I should see "your donations are eligible to be matched" in success page
• but in this case I see "check eligibility " button on staging

[Meriem-BM]

@maryjaf basically, at the start of a new QF round, if they user is making their 1st donation, we should automatically check their eligibility agains thte MBD system. if they pass (i.e if they have enough on-chain activity with that address that their score should be high enough... (no stamps)), the user would see all the "your donations are eligible to be matched" prompts without ever having to click the "check my eligibility" buttons.

@Meriem-B @CarlosQ96 based on this comment the behavior of system in this scenario isn't as expected:

• my score is more than threshold
• after doing a donation in QF round , the score check should be done automatically and I should see "your donations are eligible to be matched" in success page
• but in this case I see "check eligibility " button on staging

We haven't implemented the automatic check feature before the donation actually. I'm not sure whether it would be better to handle this on the backend or the frontend.

cc: @CarlosQ96

[laurenluz]

@Meriem-BM @CarlosQ96 - are we checking the user's score w/ the MBD API when they... sign in? if we didn't implement any auto-check feature on donation, it seems like we implemented an auto-check feature on sign in ... because when I tested this on staging w/ a new QF round and having never done any testing yet on this feature... it just said that my address was a pass and everything was ok, without me having to click any "check eligibility" buttons.

[Meriem-BM]

@Meriem-BM @CarlosQ96 - are we checking the user's score w/ the MBD API when they... sign in? if we didn't implement any auto-check feature on donation, it seems like we implemented an auto-check feature on sign in ... because when I tested this on staging w/ a new QF round and having never done any testing yet on this feature... it just said that my address was a pass and everything was ok, without me having to click any "check eligibility" buttons.

No, we are not, I think your address was added before, not sure who added to Database, but it's there with a score of 100, I just deleted, you can test again now

[maryjaf]

• We should "check" the user's address using the MBD API either (1) when the user clicks "check my eligibility" (design TBD) or (2) when the user makes their first donation to a QF project during a new QF round. (we will recheck each time there is a new QF round)

@Meriem-B @CarlosQ96 based on this comment the behavior of system in this scenario isn't as expected:

• my score is more than threshold
• after doing a donation in QF round , the score check should be done automatically and I should see "your donations are eligible to be matched" in success page
• but in this case I see "check eligibility " button on staging

We haven't implemented the automatic check feature before the donation actually. I'm not sure whether it would be better to handle this on the backend or the frontend.

cc: @CarlosQ96

So the score auto checking by doing a donation in a round, should be developed or not?

[CarlosQ96]

It will break some users the first time. If we do it, we will need to do it in a job or separated process that doesnt break the requests or donations will start to fail. @Meriem-BM @maryjaf Or better, when it logs in, we do it here in a job if the user doesnt have a score for that qfround yet. @Meriem-BM what do you think?

Tho I rather not break donation flow. The MBD score can take 15 seconds first time.

[laurenluz]

yeah I think we should keep it serparate from the donation flow in that case @CarlosQ96! If we can make an auto-check upon login (if there is a new qf round)... then that's great.... but if that makes things break, worst case scenario we can require that the user clicks that "check eligibility" button somewhere... it's not a horrible fallback.

[Meriem-BM]

yeah I think we should keep it serparate from the donation flow in that case @CarlosQ96! If we can make an auto-check upon login (if there is a new qf round)... then that's great.... but if that makes things break, worst case scenario we can require that the user clicks that "check eligibility" button somewhere... it's not a horrible fallback.

@laurenluz can we postpone this for the 2nd phase, I believe I'll need Carlos guidance on this.

cc: @maryjaf @koday1

[laurenluz]

yeah sure! so then right now in our flow... basically there is no "auto-check" at all? The user always will have to click "check eligibility" to compare their score against the MBD threshold @Meriem-BM ?

If that's the case, I think we can call this good for this dev phase... and we can make a new issue to implement an "auto-check" that Carlos can support w/ when he's back from vacay.

The MVP version we need to have full fixed & pushed to prod before the arbitrum round starts (so ideally it's finished and on prod by the end of this week)

[Meriem-BM]

yeah sure! so then right now in our flow... basically there is no "auto-check" at all? The user always will have to click "check eligibility" to compare their score against the MBD threshold @Meriem-BM ?

Yes, exactly, there is no "auto-check" for now.

If that's the case, I think we can call this good for this dev phase... and we can make a new issue to implement an "auto-check" that Carlos can support w/ when he's back from vacay.

The MVP version we need to have full fixed & pushed to prod before the arbitrum round starts (so ideally it's finished and on prod by the end of this week)

Sure.

[laurenluz]

ok created issue https://github.com/Giveth/giveth-dapps-v2/issues/4466

@maryjaf if you can test/valid this issue w/o any auto-check, we're good to go :-D

[maryjaf]

@Meriem-BM By tapping on "Connect Gitcoin Passport" a signature modal in metamask is shown by tapping on reject this message is shown

User rejected the request.\n\nDetails: User rejected the request.\nVersion: viem@2.16.1

could a handheld message be shown like "User rejected the request." ? or this message is fine

https://github.com/user-attachments/assets/b8b43e41-8ca0-4262-a5c2-de0ef280dea1

[Meriem-BM]

@Meriem-BM By tapping on "Connect Gitcoin Passport" a signature modal in metamask is shown by tapping on reject this message is shown

User rejected the request.\n\nDetails: User rejected the request.\nVersion: viem@2.16.1

could a handheld message be shown like "User rejected the request." ? or this message is fine

Fixed, you can check this now @maryjaf

[maryjaf]

Thanks @Meriem-BM It has been fixed