If this becomes an issue, there is an approach that might work : Just use multiple signing keys, one system wide key C for all CloudFlare sites, and individual site keys for each site CloudFlare protects. If you solve a CAPTCHA then you withdraw a moderate stack of C tokens. If you visit site X then you spend an X token if you have one, but if you do not then you spend a single C token to withdraw tens of thousands of X tokens. So solving a CAPTCHA is worth hundreds of thousands of page loads, but only across a moderate number of sites. We could've separate Cbig and Csmall keys such that first it withdraws with Csmall, but if the users blows through that quickly then it withdraws with Cbig.

The spec already accounts for this by giving out a single-domain cookie to any client that successfully redeems a token. We'd need to figure out how long these cookies last for (a day perhaps?), but the idea is that the client would no longer need to redeem any more tokens for that domain. Each token effectively guarantees you access to a resource for the given time period.

Because of this we have reduced the number of tokens that should be handed out. For example in the original spec 10,000 tokens were talked about as a reasonable amount whereas in our implementation we use somewhere between 100 and 1000. In our implementation we struggled to work with more than 1000 tokens without rendering the browser complete useless for a fairly long time period anyway, since the extension has to verify and unblind each of the tokens it receives.

Alex