Problem
EligibilityModule._checkVouchingRateLimit has a new-user restriction check, but userJoinTime is never set during the QuickJoin onboarding flow. Since NEW_USER_RESTRICTION_DAYS = 0, this is currently a non-issue, but if the restriction period is ever increased, the check would be bypassed entirely for users who joined via QuickJoin.
Additionally, with NEW_USER_RESTRICTION_DAYS = 0, an attacker can create Q passkey accounts via QuickJoin (which auto-grants membership hats), and all Q accounts can immediately vouch for an attacker-controlled address, granting it any vouch-gated hat (where Q = vouch quorum).
Impact
Vouch-gated roles can be acquired by a single attacker controlling Q accounts, undermining the vouching system's trust model.
Recommended Fix
- Set
userJoinTime during QuickJoin onboarding (call eligibilityModule.setJoinTime(user, block.timestamp))
- Consider setting
NEW_USER_RESTRICTION_DAYS to a meaningful value (e.g., 7 days)
- Consider requiring the voucher to NOT have been vouched-in themselves within the same period (transitive trust delay)
Severity
High — Backlog
Problem
EligibilityModule._checkVouchingRateLimithas a new-user restriction check, butuserJoinTimeis never set during the QuickJoin onboarding flow. SinceNEW_USER_RESTRICTION_DAYS = 0, this is currently a non-issue, but if the restriction period is ever increased, the check would be bypassed entirely for users who joined via QuickJoin.Additionally, with
NEW_USER_RESTRICTION_DAYS = 0, an attacker can create Q passkey accounts via QuickJoin (which auto-grants membership hats), and all Q accounts can immediately vouch for an attacker-controlled address, granting it any vouch-gated hat (where Q = vouch quorum).Impact
Vouch-gated roles can be acquired by a single attacker controlling Q accounts, undermining the vouching system's trust model.
Recommended Fix
userJoinTimeduring QuickJoin onboarding (calleligibilityModule.setJoinTime(user, block.timestamp))NEW_USER_RESTRICTION_DAYSto a meaningful value (e.g., 7 days)Severity
High — Backlog