There are two options that Upala can be integrated with Gitcoin. These options can be used as alternatives or as stages - one after another. Both options follow the same strategy which is explained below. The integrations are explained further. And some future thoughts are included even furtherer.
Bribe bots to leave
As proposed earlier in this tweet the strategy is as follows:
Set. Assign Upala score to each of the verification methods.
Wait. See how many users will explode*.
Repeat. Tweak scores for each verification method.
*Explode = run away with the score (money), delete Upala ID, delete Gitcoin ID.
Set
Setting the score for the first time is just guessing. But it makes sense to start with low scores for verification methods. It is fairly simple to increase the scores at any time. But If the scores are too high we'll see too many explosions from the start (and will not be able to do anything until attack window expires - presumably 1 hour).
Wait
At this stage users are gonna explode, take their explosion rewards (which are equal to their scores) and delete both their Upala and Gitcoin accounts. This is the time to analyze stats.
If a verification method is too easy to exploit, we'll see a lot of users verifying themselves and creating new gitcoin accounts just for the sake of explosion reward. That would mean that we have to lower that verification method score. And we can increase the score for stronger verification methods.
Repeat
Here are proposed global parameters to quickly asses and reset the score:
Period. Time-frame during which the explosions analytics is gathered. We could tie this period to Matching Rounds or make it as short as 1 hour. The only constraint here is Upala's front-run prevention, which requires a 1 hour pause (bot attack window) before new scores take action.
Explosion rate. Metrics for each verification method. Could be measured as
( total explosions reward payed ) / ( number of people verified )
Threshold. Desired explosion rate for every verification method.
Step. A step or a factor by which scores are increased or decreased for the next period when crossing the threshold.
Benefits
Refine your audience. As some users will decide to get the money rather than participate in Gitcoin there will be a number of bots leaving the platform. But the remaining ones are your super-users. They value their IDs higher than their scores. It is safe to give them more privileges.
Metrics. Treat a new verification method as an investment and measure its "ROI". Compare explosion rate and activity of users withing the category.
Fairer trust bonus. Tweak trust bonuses according to the price-of-forgery of a verification method.
1. Assess existing verification methods
It's the first option of Gitcoin and Upala integration. Here we use current active verification methods to set Upala user score.
After some Set-Wait-Repeat stats is gathered, we establish a fixed ratio between Upala score and trust bonus. Then reset all trust bonuses accordingly. Thus the trust bonus will reflect the trustworthiness of a verification method (as the score provided by the method represents its forgery price).
When first introduced, Upala may provide additional scores to all other methods. This would create an additional incentive to use all verification methods and to use Upala (in order to start gathering stats early).
2. Add other verification methods through Upala
Another way to integrate Upala is to have an Upala group with it's own verification methods. This could be used as an alternative to the above integration or as an extension of it. Any number of verification methods could be added here (those could be provided via Multipassport interface).
*Existing users - the ones that existed before implementing Upala.
3. Use other Upala score providers (from future)
Gitcoin may approve other Upala groups (not owned by Gitcoin) as its score providers. If a user manages to increase their score outside Gitcoin, their trust bonuses could be increased accordingly.
Gitcoin as a score provider
Upala score provided by Gitcoin group will be instantly available to other DApps if they chose to trust Gitcoin (why wouldn't they?). Gitcoin may charge DApps for this. Pretty cool!
Upala + Gitcoin user base = Sybil-proof Ethereum
...or Gitcoin may decide not to provide scores into the outside world.
Tech details (for option 1)
User registers Upala ID on Gitcoin Trust Bonus page
Gitcoin periodically assigns scores to all registered Upala IDs off-chain and publishes a Merle root of IDs and scores on-chain.
Users make a transaction with a Merle proof to assign scores to themselves.
There are two options that Upala can be integrated with Gitcoin. These options can be used as alternatives or as stages - one after another. Both options follow the same strategy which is explained below. The integrations are explained further. And some future thoughts are included even furtherer.
Bribe bots to leave
As proposed earlier in this tweet the strategy is as follows:
*Explode = run away with the score (money), delete Upala ID, delete Gitcoin ID.
Set
Setting the score for the first time is just guessing. But it makes sense to start with low scores for verification methods. It is fairly simple to increase the scores at any time. But If the scores are too high we'll see too many explosions from the start (and will not be able to do anything until attack window expires - presumably 1 hour).
Wait
At this stage users are gonna explode, take their explosion rewards (which are equal to their scores) and delete both their Upala and Gitcoin accounts. This is the time to analyze stats.
If a verification method is too easy to exploit, we'll see a lot of users verifying themselves and creating new gitcoin accounts just for the sake of explosion reward. That would mean that we have to lower that verification method score. And we can increase the score for stronger verification methods.
Repeat
Here are proposed global parameters to quickly asses and reset the score:
Period. Time-frame during which the explosions analytics is gathered. We could tie this period to Matching Rounds or make it as short as 1 hour. The only constraint here is Upala's front-run prevention, which requires a 1 hour pause (bot attack window) before new scores take action.
Explosion rate. Metrics for each verification method. Could be measured as
( total explosions reward payed ) / ( number of people verified )
Threshold. Desired explosion rate for every verification method.
Step. A step or a factor by which scores are increased or decreased for the next period when crossing the threshold.
Benefits
Refine your audience. As some users will decide to get the money rather than participate in Gitcoin there will be a number of bots leaving the platform. But the remaining ones are your super-users. They value their IDs higher than their scores. It is safe to give them more privileges.
Metrics. Treat a new verification method as an investment and measure its "ROI". Compare explosion rate and activity of users withing the category.
Fairer trust bonus. Tweak trust bonuses according to the price-of-forgery of a verification method.
1. Assess existing verification methods
It's the first option of Gitcoin and Upala integration. Here we use current active verification methods to set Upala user score.
After some Set-Wait-Repeat stats is gathered, we establish a fixed ratio between Upala score and trust bonus. Then reset all trust bonuses accordingly. Thus the trust bonus will reflect the trustworthiness of a verification method (as the score provided by the method represents its forgery price).
Scores and trust bonuses for the active verification methods (Notion)
Boosted bonus
When first introduced, Upala may provide additional scores to all other methods. This would create an additional incentive to use all verification methods and to use Upala (in order to start gathering stats early).
2. Add other verification methods through Upala
Another way to integrate Upala is to have an Upala group with it's own verification methods. This could be used as an alternative to the above integration or as an extension of it. Any number of verification methods could be added here (those could be provided via Multipassport interface).
Verification methods (Notion)
*Existing users - the ones that existed before implementing Upala.
3. Use other Upala score providers (from future)
Gitcoin may approve other Upala groups (not owned by Gitcoin) as its score providers. If a user manages to increase their score outside Gitcoin, their trust bonuses could be increased accordingly.
Gitcoin as a score provider
Upala score provided by Gitcoin group will be instantly available to other DApps if they chose to trust Gitcoin (why wouldn't they?). Gitcoin may charge DApps for this. Pretty cool!
Upala + Gitcoin user base = Sybil-proof Ethereum
...or Gitcoin may decide not to provide scores into the outside world.
Tech details (for option 1)
Smart-contract draft here.
Off-chain front-end, back-end - https://github.com/trustlines-protocol/merkle-drop
More info:
Join us:
@owocki 👀