Count the whole incentive
A referral reward can be the visible incentive while the new account's ordinary allowance is the larger exposure. Model both. For N additional accounts, an allowance of F credits, a referral reward of R credits, and a reward cap of C, the simple monthly upper bound is N × F + min(N, C) × R. That assumes every extra account qualifies and all credits can be used.
Use an example, not a forecast
With 10 hypothetical additional accounts, 2,000 credits per account, a 100-credit reward, and a cap of 10 rewards, the model yields 21,000 credits: 20,000 in ordinary allowances and 1,000 in rewards. These are illustrative inputs, not an estimate of actual abuse or a promise that prevention would recover that amount.
Make your assumptions visible
The calculator intentionally ignores identity checks, domain caps, expiry, request rates, and credit consumption. That makes it useful as a starting upper-bound model. Your realized cost also depends on marginal cost per successful check. List price is not necessarily your operating cost. Keep credit exposure and money separate unless you have reliable cost data.
Protect the grant, not just the button
The server needs to decide eligibility and record a reward once. Repeated requests, concurrent verification, or account deletion must not silently create another eligible claim. A UI message or a disabled share button cannot provide that guarantee. Preserve enough purpose-limited state to enforce the policy, and disclose what remains after deletion.
Change one policy at a time
Possible controls include account-identity limits, a referrer cap, a per-domain reward cap, or a later activation milestone. Each has a cost: a strict shared-domain cap can affect unrelated customers using a popular provider. Choose controls around the exposure you actually have, measure legitimate conversion, and document the reward trigger so customers are not surprised.