Smart contract to verify an address and for accept an invitation

[andresaiello]

Summary

• Register contract to verify an address
• Reference contract to accept a referral code

[lucas-janon]

I see a potential vulnerability (low) that goes like this:

• I create an invite signature.
• Someone accepts my invite.
• An attacker gets my invite signature since it's public.
• The attacker creates thousands of accounts and gets all of them to be invited by me.
• My inviteeList gets extremely long and I get no benefits since they're capped to N invites a week.

I think it's not too bad since we don't iterate over an inviteeList on any function, but I think a very long list may cause view issues.

On top of that, we have getInviteeAtIndex, shouldn't we at least make index part of the InvitationAccepted event? So there's more information available to query that function.

[andresaiello]

I see a potential vulnerability (low) that goes like this:

• I create an invite signature.
• Someone accepts my invite.
• An attacker gets my invite signature since it's public.
• The attacker creates thousands of accounts and gets all of them to be invited by me.
• My inviteeList gets extremely long and I get no benefits since they're capped to N invites a week.

I think it's not too bad since we don't iterate over an inviteeList on any function, but I think a very long list may cause view issues.

On top of that, we have getInviteeAtIndex, shouldn't we at least make index part of the InvitationAccepted event? So there's more information available to query that function.

that's why we have getInviteeAtIndex and not iterate the list and return the list to avoid any out of gas issue. I agree to add the index, I will do it now

[lucas-janon]

LGTM