The official document says:
Each time you register a .bit account, its promoter (if any) and agent will be rewarded with 10% of the registration fee.
This article will reveal some details about the reward
What is the reward
We will use CKB as the rewards for the convenience, since the reward logic had been written into the contract on chain.
Who is the rewardee
How it works
Before explaining how .bit deal with the reward, we need to popularize the famous 61 problem on CKB
61 problem on CKB
The traditional reward method is generally to divide 10% of the registration fee, and transfer it to the beneficiary address directly. But this simple operation is not possible on CKB due to 61 problem. for example:
Assuming that the unit price of CKB is $0.01, $5 will get 500 CKB, then 10% is 50 CKB, And
inviteris probably a das-lock, while the base capacity of the das-lock is at least 83 CKB(even for an normal CKB cell, its base size is 61), because the reward is smaller than the base capacity, it cannot be directly transferred to the beneficiary.
.bit solution
In order to solve the above problem, .bit introduces a cell called income-cell concept .
To put it simply, a reward ledger is stored in the income-cell. The cell’s capacity is equal to the total amount of all reward records in it. And then wait for keeper to scan all income-cells in the whole network. The keeper will finally send the appropriate amount of reward (greater than 126, to be precise: 120 / 0.95 = 126.32) to the beneficiary, and the beneficiary will receive at least 120 CKB. So this is why every time the reward arrives, it exceeds 120 CKB.
Take the following figure as an example. Since the total reward recorded by inviterA in IncomeCellA and IncomeCellB is greater than 126 CKB, these two income-cells can be merged into one IncomeCellC:
Why the rewards not received
Case 1
The reward is less than 126 CKB, and is making its contribute to maintaining some income-cell, just like the inviterB, inviterC, inviterD and inviterE do in the picture above. :)
Case 2
There will be a few cases where the total reward of an inviter exceeds 126 CKB but the reward is still not received.
As shown in the picture below, although the total reward of inviterA has exceeded 126, the keeper still cannot merge the two income-cells into one, because the total reward of all remaining inviters is not enough to make up the basic capacity of a new income-cell (200 CKB) .
In short, the rewards of .bit are distributed in real time. As long as the user registers successfully, the reward distribution is completed. But the reward may not be transferred immediately, but it will not be delayed for too long.